Tag: modularDesign

Always design a thing by considering it in its next larger context

On By twobenchesIn drivethru, emergency laneLeave a comment

“Always design a thing by considering it in its next larger context”, said the Finnish architect Eliel Saarinen. “A chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

When designing for the web, it’s tempting to think in terms of interactions like swiping, tapping, clicking, scrolling, dragging and dropping. But very few people wake up in the morning looking forward to a day of scrolling and tapping. They’re more likely to think in terms of reading, writing, sharing, buying and selling. Web designers need to see past the surface‐level actions to find the more meaningful verbs beneath.

In their book Designing With Progressive Enhancement, the Filament Group describe a technique they call “the x‐ray perspective”:

Taking an x‐ray perspective means looking “through” the complex widgets and visual styles of a design, identifying the core content and functional pieces that make up the page, and finding a simple HTML equivalent for each that will work universally.

Jeremy Keith: Resilient Web Design

Atomic Design

On By twobenchesIn emergency lane, picnic siteLeave a comment
  • atoms
    In chemistry, atoms are the basic building blocks of matter. They have distinct properties and can’t be broken down further without losing their meaning. Translated to interfaces, atoms are basic tags, such as form labels, inputs or buttons. They also include more abstract elements like color palettes, fonts, and animations. Atoms are abstract and aren’t often terribly useful on their own, but they provide a useful reference and allow you to see all your global styles laid out at a glance.
  • molecules
    In chemistry, molecules are groups of atoms bonded together, which take on new properties as a result.
    In interfaces, molecules are groups of elements that function together as a unit. For example, a form label, search input, and button atom can combine them together to form a search form molecule. Building up from atoms to molecules encourages a “do one thing and do it well” mentality, and encourages creating reusable interface patterns.
  • organisms
    Organisms are groups of molecules (and possibly atoms) joined together to form distinct section of an interface. Organisms can consist of similar and/or disparate molecule types. For example, a masthead organism might consist of a logo, navigation, and search form, while a “product grid” organism might consist of the same product info molecule repeated over and over. Building up from molecules to organisms encourages creating standalone, portable, reusable components.
  • templates
    With templates, we break our biochemistry analogy to get into language that makes more sense to clients and final output. Templates are comprised mostly of organisms combined together to form page-level objects. Templates provide context for these relatively abstract molecules and organisms, which is helpful for designers and clients alike. Templates mostly focus on content structure (such as character length, image size, etc) rather than the actual content.
  • pages
    Pages are specific instances of templates and swap out placeholder content with real representative content to give an accurate depiction of what a user will ultimately see. Pages are essential for testing the effectiveness of the design system. This final form allows us to loop back to modify our molecules, organisms, and templates to better address the real context of the design. Pages also provide a place to test variations in templates, such as testing an article containing a 40-character-length headline and other article with a 340-character-length headline. What does it look like when a user has one item in their shopping cart versus 10 items with a discount code applied? These specific page instances test the resiliency of the system, influencing how the underlying molecules, organisms, and templates are constructed.

Brad Frost: Patternlab

Modularizing designs

On By twobenchesIn drivethruLeave a comment

What Federico points out is that a ship, a building, and a car are merely collections of components. Components are manageable and flexible. So long as the components join together seamlessly in the end, modularizing the pieces translates to flexibility, speed, and paradoxically both independence and collaboration.

“I began to think in terms of “designing software for mass manufacture.”

“The end result is a system—a system of individual and interchangeable parts that start at the smallest possible level and grows from there. Components are then assembled from these individual parts, and these components make up some of the core parts of our app. Once a group of components are assembled, we get a fully functioning page inside our application that is consistent in design and architecture with the other pages of our app—all because the pages share the same architecture.”

Architecting a Pattern Library by Federico Holgado

How to sell a component library to stakeholders?

On By twobenchesIn emergency lane, picnic siteLeave a comment
    General KPI’s:

  • Cost
  • Customers acquired
  • Acquiring cost
  • Churn
  • Conversion to sale
  • Size of deal
  • Customer profitability
  • Customer satisfaction
  • Support costs/case avoidance
    IT and engineering exec’s

  • Cost savings from reuse
  • Compatibility with bulletproof open source libraries
  • Lower training cost of technical staff
  • Lower quality assurance (QA) costs during release
  • Lower costs to support the code over time
  • Ability to scale up quickly to outsource due to better documentation
    Brand and Marketing

  • Improved engagement (time on site, “funnel tractors” such as wizards and videos)
  • Better conversion by using well-hones, time-tested, proven high-conversion winners)
  • Consistent visual and interaction identity for the brand, by baking the rules into the components
  • Huge time-to-market advantages
  • Lower cost with vendors, since they won’t be charging you to reinvent the wheel with each new project

Curtis (2010) p. 147-9

Is your organisation ready for a library?

On By twobenchesIn picnic siteLeave a comment
  • Communication
    Everyone else will want to know – in simple terms – what this coponent library is all about, hocalw it works, and what it means to them. Your story must be siple, concrete, direct, and focused on how each group and individual may be affected. (…)
  • Workflow
    Component libraries impact at least two critical workflows: how you produce a design solution for each project versus how you maintain your library’s assets, guidelines, and documentation across projects. (…) Depending on how much your library spreads into the activities f cross-functional teams, you’ll need to map out those impacts and come together across teams to decide how milestones, artifacts, expectations, and participation will need to shift.
  • Collaboration
    A component library can be one way for teams to improve collaboration.That said, be mindful that different disciplines may see a library in different lights. So don’t try to fit a square peg in a round hole, but seek to maximise collaboration and participation in your effort.
  • Participation
    Design and engineering teams commonly lead and own library development. But other participants can benefit from, learn from, contribute to, or even immerse their work in the foundation created by the library, too. Product managers start to author Product Requirement Documents or product backlogs that refer to components. QA begins to bind test cases to component codes and variations. Copywriters write copy, variations, and error messages mapped concretely to modular design treatments. The component library’s collaborative nature – not the design assets, but underlying principles of modular thinking and standards – can appeal to many disciplines as a platform into which to inject their influence. (…)
  • Documentation
    (…) As you roll out a library, will deliverables change dramatically, be thrown away, or even be invented from the ground up?

Curtis (2010) p.143-6