or, Maintaining a standard of design and code quality in a lean environment
A standard of quality
It goes: Strive for quality in work. Require a high standard of quality in products and services, in business. In all things: quality of design, quality of code, quality of content, quality of usability and accessibility.
How do we define a high standard of quality?
One way of valuing quality is as a measure of craftsmanship.
Craftsmanship, to quote Richard Sennett, is “a basic human impulse: the desire to do a job well for its own sake”. Craftsmanship, by definition, implies a learned — or, more broadly, a practiced — skill in a particular craft. Craftsmanship, then, is an implicit standard of high quality.
In his article Crafting the Front End, Ben Bodien considers the attributes that make a craftsman (craftsperson) the maven of their craft. They are, paraphrased: “an appreciation of good work, a belief in quality at every level, vision, a preference for simplicity, and sincerity”. Further, the article explains that a craftsman is adept at his skill by maintaining a personalized toolkit, specialized to his strengths.
Quality in collaborative work then is finding the best designers, developers, writers and content creators; those who excel at a craft and expect the same of peers.
Craftsmanship and delivery
A high standard of quality and craftsmanship would suggest careful, considered effort and refinement over a long duration of time. In an environment of agile development and lean principles — frequent release for purposes of quantitative learning — is there a conflict between work quality and the timely delivery of product? If the goal is to constantly test a product to gain user feedback and an understanding of progress, are the two constants — quality and pace — at odds?
As it stands, gaps in traditional ways of working allow for output without validation. This applies to design decisions as often as it applies to product research and feature investment. As with development, if allowed all the time in the world design quality will stagnate or diminish as authors add more and refine less. Rapid iteration is not counter-intuitive to a good design process. In fact, it is the opposite. The early concepting and sketching stages of design often need an exhausting devotion to the repetitive generation of ideas. The strength of visual design is in iteration. Similarly, rapid prototyping does not necessitate haphazard, disposable code.
The proposal then, is that there is no inherent compromise in essential — fundamental, quintessential— quality in work and the rate at which it is completed.
Elements of craftsmanship
Accepting that duration of products will differ, the pace of completion will vary, and unforeseen variables will disrupt workflows: how can we best infuse an essential standard of quality in our work? What elements of craftsmanship can shape our process? What elements of craftsmanship are at the heart of work we take pride in?
Consider a draft list of candidates.
Fundamentally usable design
Get things straight from the beginning: start with fundamentally usable design. Paul Schriver recently wrote on the notion of “Minimum Usable Design”. While the method he describes doesn’t quite live up to its premise, the term (which, admittedly is a bit silly) contains a kernel of truth. That is, favor simplicity and usability by designing for the largest user audience first. Design the aspects of a product or service that are relevant to a broad set of users. Avoid designing every feature or layout.
As we establish basics, add specialized features in iterations; prioritize the design process. In doing so, we save time and sidestep the risk of diminishing returns, as explained by Dmitry Fadeyev in response to Schriver’s article. He writes:
Once you implement the core foundation, you’ve satisfied most users, and as you go up from there, adding more and more features and refinements, the payoff for your efforts will steadily fall.
A smarter design process produces less waste and better design. This is especially crucial if the product is nested in a responsive web design workflow. Convey a broad design vision at the start, iterate as the audience returns measurable needs and the technology becomes less opaque.
Accessible, measurable concepts
Accessibility is critical to early user-testing, whether as designs presented for feedback or in product prototyping. Keep design straightforward: free of embellishment and difficult color or typographic choices. Thoroughly consider decisions, unapologetically remove unnecessary features or flourishes that put accessibility and testing in jeopardy.
A prototype or Minimum Viable Product (MVP) must be usable by the users testing it; measurable feedback is only useful if consistent and trusted. In cases where a single technology or browser scenario is not specified in early testing, always aim for broad compatibility on different devices.
Follow the rules! The Web Content Accessibility Guidelines (WCAG) tell us everything we need to know to build compliant web services. Additionally, keep note of HTML5 support for The Roles Model (ARIA). Be mindful of users with visual impairments and learning disabilities. Simulate users environments where you can, consult with experts where you cannot.
User experience modeled on shared and personal learning
Ben Bodean, in his article on craftsmanship, wrote on the importance of a craftsman’s toolkit. He provides it as a metaphor for the tools and knowledge we collect to enable our craft in a chosen field. We specialize each toolkit through the tools, and individualize by our unique, particular experiences.
In terms of design, our toolkit is a personal collection of layouts, concepts and recurring patterns that we find online, in publication, on the street. There is a parallel to the photographer’s morgue of editorial shops and studios. It is the scaffolding borrowed from the shared libraries of our peers; the templates and stencils we forage to fill the gaps in our software applications.
Design, and the process of establishing user experience, is stronger for shared material. Building on the learnings of others makes for an efficient and timely process, but more importantly reduces the potential for repetitive mistakes. Accepted user behaviors, design patterns — a cumulative result of the trial and error of others.
Modular, reusable patterns of code
In the same way, front end development should encourage reusability. Stop redundancy and repetition by stashing pieces of code. Pool from previous projects, build a centralized repository. Use snippets in text editors. As you assemble a toolkit, prepare a collection of common, reusable markup and style patterns. Examine standard elements for commonality; how often does the underlying markup for lists, headings, tables, navigation and content styling change? The best minds in the industry insist on modularity — for example Dan Cederholm’s pea.rs, Jeremy Keith’s Pattern Primer and the BBC’s Global Experience Language.
If possible, build and keep lightweight framework skeletons and vanilla themes with basic functionality, without the frills. Import entire bits of previous projects when starting something new. Be lazy, efficient and advocate cohesion.
Output adhering and contributing to, a guide of living standards
The simplest way to maintain quality is to ensure consistency. As organizations and teams often change, the most reliable way of keeping a legacy of regularity in work or appearance is through guidelines, or style guides. Newspapers have written and adhered to their own language style guides for a century; transportation networks, large corporations and cultural institutions achieved visual uniformity through graphic design in the mid-20th century. Style guides are keystones of modern branding.
Design guidelines determine typographic selection, a color palette, image treatment, the outlay of a complex grid system. Language style guides set a tone of voice, punctuation and spelling, the context and definition of words.
In her article on style guides, Anna Debenham provides a number of excellent examples, as applied to both design and front end development.
Development guidelines offer the same possibility as their printed precursors. From detailing code conventions as minute as indentation and capitalization to providing accessible and standards-compliant examples of common markup patterns, development guidelines have the potential to persist as evangelists of good code on ever-shifting products.
As software products mature, the developers and teams mobilized to build them often move to other projects. In an agile work environment, it is not uncommon to bring on developers from outside the team as needed to fulfill a temporary increase in work. Every developer arrives with different experiences, opinions and preferences. Proper documentation and guidelines are a practical way to stop your product from evolving into a zombie Frankenstein, cobbled together from wildly varying bits of code.
It is useful to start with the conventions of others. Google, Tait Brown, Paul Lloyd, Nicholas Gallagher and Richard Hallows all provide wonderful examples. However, for an organization with shifting staff, writing one as a team is ideal. Take inspiration from other guides, but taylor it to the team’s quirks and practices. The document is not static, but always open to correction and expansion; a living standard. Dock this knowledge in a versioned repository to take advantage of branching and revision history.
On the topic of design, it may not be appropriate to place brand or visual guidelines on an organization, particularly if the organization specializes in making products for others. Instead, perhaps an umbrella guide of suggestions, nudges and hints to bake in an instinctual feel of connected identity.
To this point: Essential quality as elements of craftsmanship, placed brick by brick as a foundation for your workflow. However, as it goes, knowledge isn’t very useful if not shared. Craftsmanship is a fine thing as an individual. Collaborative work amongst talented makers, however, is only as successful as the platform they share.
Define and share guidance. Encourage peer reviews, critiques, group presentations. Expect technical documentation and open data culled from research and measured learnings. Centralize resources: single points of access for design assets and templates, repositories of protected source code.
A proverbial well-oiled machine
The less obstacles in a product cycle, the sooner users give feedback, the stronger a design — a hypothesis — pushed through iteration will be. By establishing a standard of quality, focus can move exclusively to rapid release cycles, testing and intuitive decision-making. By establishing a standard of quality, all output — no matter how temporary or disposable — is accessible, lean, and fundamentally usable.
As work cycles inevitably stagger or drift, pause and reflect. Nothing is so urgent that it is not susceptible to questions of relevance. As Ben Bodean wrote, on craftsmanship and quality:
A good craftsperson regularly takes a step back from their work, and questions every facet of their product for its precise alignment with their core values of quality and sincerity.