{"id":453,"date":"2018-07-13T04:18:40","date_gmt":"2018-07-13T04:18:40","guid":{"rendered":"https:\/\/blog.hassler.ec\/wp\/?p=453"},"modified":"2018-06-27T17:23:47","modified_gmt":"2018-06-27T17:23:47","slug":"an-interaction-design-framework-to-cover-all-your-bases","status":"publish","type":"post","link":"https:\/\/blog.hassler.ec\/wp\/2018\/07\/13\/an-interaction-design-framework-to-cover-all-your-bases\/","title":{"rendered":"An interaction design framework to cover all your\u00a0bases"},"content":{"rendered":"
\n
\n
\n

Pointers to keep in mind before delving deep in micro-interactions and pixel level\u00a0details.<\/h2>\n

My first few years as a designer involved a lot of learning that was mostly through trial and error. It usually followed the format of\u200a\u2014\u200aunderstand the problem, try a few ideas out, guess what process works best, and go ahead and do it. This way of designing definitely did teach me quite a bit and I learned about dead-ends as and when I approached them. In my naive years, there was not too much thought put into an organized way of doings things. As I grow as a designer, I have noticed myself building frameworks and process guidelines for myself. This has been necessary because of the impact the designs achieve, the stakes involved, and the scale of the projects.<\/p>\n

With increasing stakes of the designs, it is important to iron-out details and get\u00a0as much\u00a0<\/em>right in the MVE (minimal viable experience; I don\u2019t believe in MVPs, and that\u2019s for a different discussion) that I am designing for.<\/p>\n

Over the years, I found myself going back to the drawing board because I missed out some key elements of the design flow. On retrospective, I realized this was because I was not really following a format to iron out the designs before the hand-off.<\/p>\n

Engineers really love having complete designs that are well thought-through and are logically thorough.<\/p><\/blockquote>\n

Enter the Framework<\/h3>\n

To aid with thorough designs, I came up with a framework that tries to cover all bases of the flow that I am designing. Some instances, it has proven to be helpful in thinking about cases that were not thought through earlier in the process.<\/p>\n

The framework that I use is nothing that we designers already don\u2019t do, but it is a conglomeration of the important pointers that we sometimes tend to forget while designing.<\/p>\n

The framework consists of four sections that I like to divide my designs into \u2013<\/p>\n

    \n
  1. Happy Path<\/li>\n
  2. Edge Cases<\/li>\n
  3. Transitions & Animations<\/li>\n
  4. Content\/Messaging<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
    \n
    \n
    \n<\/div>\n
    \n
    \n

    Happy Path<\/h3>\n
    \n
    \n
    <\/div>\n
    <\/canvas><\/div>\n<\/div>\n<\/figure>\n

    This is something that almost all designers do with certainty. If we are designing a way for a person to book a flight ticket, what is the ideal journey going to look like? Starting from choosing dates of travel, to selecting a flight, and the checkout process. This ideal path is something that I lay out first without thinking about the what-ifs. I iron out the specific details of the ideal path without paying attention to any edge-cases. I call this the\u00a0user journey without any quirks.<\/em><\/p>\n

    This is a no-brainer but allowing yourself to think only about the ideal journey and not be bothered by the edge-cases helps in focusing on the flow and not get carried away. This conscious session helps me jot down questions that come to my mind about the what-ifs but not pay attention to the design of the what-ifs.<\/p>\n

    The Scenarios of the Happy\u00a0Path<\/h4>\n

    The next step to this phase is accounting for the different scenarios. Many would argue that accounting for different scenarios does not mean you are designing the ideal journey. In my view, scenarios are different from edge-cases.<\/p>\n

    For example, in Enterprise design, you usually have multiple scenarios of a particular flow. How does a particular flow seem when a setting is enabled or disabled. What does a tertiary state look like\u200a\u2014\u200athat is neither disabled nor enabled but a dormant state.<\/p>\n

    Accounting for scenarios does not apply to all design flows but definitely helps in being mindful.<\/p>\n

    Another example of different scenarios\u200a\u2014\u200asay on Google Maps, what does the new experience you are designing look like when voice is disabled, or when the map theme is in night mode? Listing out the different possible scenarios early in your design process will allow you to identify sub-journeys that could have been easily missed.<\/p>\n

    This is ideally just branching out the different possibilities of the ideal journey by creating sub-journeys if necessary of just the happy path.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

    \n
    \n
    \n<\/div>\n
    \n
    \n

    Edge Cases<\/h3>\n
    \n
    \n
    <\/div>\n
    <\/canvas><\/div>\n<\/div>\n<\/figure>\n

    You are in the good books of the engineers you work with the minute you start accounting for all the possible edge-cases. In my working experience, there are two types of edge-cases that occur on a regular basis \u2014<\/p>\n

      \n
    1. User initiated edge cases<\/strong><\/li>\n
    2. System generated<\/strong><\/li>\n<\/ol>\n

      User Initiated edge cases
      \n<\/strong>There are cases when a user erroneously performs an action that is not expected of them in an ideal flow.<\/p>\n

      Let\u2019s take some examples here –<\/p>\n