Patrick Marsceill's Articles on Cognitionhttps://cognition.happycog.com/feed
A blog by the folks at Happy Cogencontact@happycog.comCopyright 2020Thu, 30 Apr 2020 13:03:44 GMTOrganic Artifactshttps://cognition.happycog.com/article/organic-artifacts
Patrick Marsceillhttps://cognition.happycog.com/article/organic-artifacts#id:244#date:16:36I first learned of Wharton Esherick when I took an impromptu trip to his studio outside of Philadelphia. Though he has long since passed, his live-in workspace has been preserved and was well worth the 45 minute drive. Esherick is known for many things, as a sculptor and woodworker he was acknowledged as the “dean of American craftsmen” by his peers and pushed the Arts and Crafts movement forward toward organicism and cubism.

Seeing his home and studio in person, I was struck by how every inch of it purposefully balanced beauty and utility in a way that could only come through years of evolution. The site, a piece of art itself, was designed and refined as the artist lived, worked, and grew there—not born out of a single explicit construction plan. There are many details that were created at different phases of the artist’s life, establishing a refined sense of organic order. What began as a humble room to create art, was given more purpose with a living quarters, a bedroom for his son, a kitchen, a silo, a bathroom, and a deck. The artist sculpted the building and its contents around the changes in his work and his life.

Well designed things—processes, websites, houses, furniture, etc.—accommodate change. As a designer, I think about change as a focal point: how sites might change after they’ve launched, how I’ve changed professionally, how my work changes throughout the design process. Recently, I’ve explored how the artifacts I make might change from project to project (and throughout each) in an effort to more effectively communicate to peers and clients. Communicating design in different ways provides a freedom to reshape the design process when situations and teams allow for it.

There is a mutual frustration that occurs when good ideas are lost in deliverables that aren’t effectively understood. It’s easy to blame a sitemap’s poor reception on a “Jan from accounting” because she didn’t understand the document’s purpose—but it probably wasn’t the right artifact for her to begin with. Even if the taxonomy described in the document was perfect, the abstract nature of how the design was communicated can be problematic.

A more effective way to describe design might mean delivering something that actually looks like a website sooner in the process. On a recent project, my team delivered several Photoshop mockups of small screen navigation systems as the first design deliverables, in lieu of a sitemap. This accomplished three things:

It documented the taxonomy and navigation as well as setting the expectation that things were supposed to organically change as part of the process. As we lived with the navigation designs and tested them against the site’s goals, the client was able to understand how our decisions affected the architecture in a practical way.

We were able to gut-check the initial aesthetic choices of color and typography along with the our first version of taxonomy. Because the work was done on small screens first, layout options were constrained and a limit was placed on how much aesthetic thinking was required up-front.

Fewer, more meaningful things were created before the actual site was built. This meant less documentation to maintain and less time before an initial version of the site was in the browser that we could test.

As I’ve experimented with different ways to communicate design, it’s become apparent that how an artifact communicates can be as critical as the actual ideas it contains. By evolving our process to better consider the needs of those involved, the artifacts supporting our process become more valuable. Esherick’s studio is a physical shrine to flexibility and growth in craft, process, and in life. Making things that accommodate change as a goal, elevates our work to be more easily understood, longer lasting, and evolve in ways originally unimaginable.

]]>TopicsDesignProcessUser ExperienceSat, 04 Jul 2015 16:36 GMTThe Crackshttps://cognition.happycog.com/article/the-cracks
Patrick Marsceillhttps://cognition.happycog.com/article/the-cracks#id:223#date:16:45The holiday break is one stretch of time during the year when I completely remove myself from the business of building the web. Stepping outside our community to engage with old friends and family members provides a much-needed recharge and change of perspective.

In the course of conversation, what I do for a living sometimes surfaces with an innocent query like, “So are you a programmer or a designer?” To which I usually try to quickly think of a vague enough response to diffuse the line of questioning. I could just choose an answer and call it a day, but not without feeling an awkward guilt from not telling the truth.

While my title at Happy Cog carries “designer,” my discomfort has very little to do with the job title itself and more with what I am trying to achieve. Choosing to tell someone that my role is to either create a site’s graphics or write its code isn’t really true. If part of my day is spent in a text editor writing CSS for a layout, does that make me a front-end developer? What if I’m drawing user flows on whiteboards for an afternoon, or in Photoshop fine-tuning typography, or talking on the phone to clients about content strategy? Even for code-averse designers, design doesn’t screech to a halt once a client approves aesthetic choices or after a site passes usability testing flawlessly. Likewise, a site’s underlying structure and styles aren’t born in code, and its content isn’t created in a vacuum. We all work toward the same thing: the execution. It’s the only part of our process that users get to interact with, so we better make it great.

When users have a good experience on a site, it’s rare that they even think about the circus that went into making it happen. The design system is cohesive, content is digestible, patterns are recognizable, taxonomy is organized, markup is semantic, styles are cascading, assets are compressed, server-side caching is humming swiftly, and all is well with the world. Things just work.

Cracks in the experience begin to form when role-based processes break down. Sometimes these cracks are small. Maybe a piece of content is buried, or a button is styled with more padding than intended. Perhaps someone tagged something incorrectly, or a style is written using the wrong values. Over time, large gaps can form. A once-sturdy navigation can no longer support a site’s overgrown taxonomy, or a headline obfuscates an improperly sized feature photograph.

Cracks develop not because we didn’t read enough design books or master all the shortcuts in Sublime Text. Somewhere along the way, one person’s knowledge was not sent, received, or acted on. The more we intentionally overlap our roles in the journey toward the execution, the easier it is to patch up those cracks—or avoid them altogether.

]]>TopicsDesignProcessTeamThu, 05 Feb 2015 16:45 GMTBetter User Testinghttps://cognition.happycog.com/article/better-user-testing
Patrick Marsceillhttps://cognition.happycog.com/article/better-user-testing#id:140#date:15:44“We don’t have the budget or time for user testing,” is something I’ve heard all too often during planning and estimating meetings. Testing with real users has traditionally been an expensive and time-consuming line item in project plans—usually one of the first to be cut when budgets are tightened. It’s no mystery why: most testing methods have classically been stressful to set up, requiring a tremendous amount of scheduling, coordination, resources, and time.

When I conducted my first usability test, I felt extremely tense. I was given a sliver of hours to painstakingly figure out how to turn a dense wireframe document into a testable, interactive system. Recruiting seemed to take forever, and some recruits inevitably flaked out. Running the tests required cold calling a large number of recruits, many of whom were non-technical and very impatient with the computers and software used to run the tests. At the time, I didn’t think being a designer would ever mean having to face these sort of obstacles. The thing that haunted me the most, though, was the possibility that the designs that my team and I worked so hard on would fail.

Why Designers Should Run the Tests

My early struggles taught me a valuable lesson: engaging with users in realtime while they interact with a system is very different from reading a report about it after the fact. The more testing experience I got, the more personal accounts I gained—which continue to shape how I approach design problems to this day. Testing not only helped me make better design decisions on a particular project, but it also trained me to make even better design decisions well after a project had ended, or as Mr. Hoekman Jr. put it:

Adding value is within your budget.

At a fraction of the cost of traditional lab testing, remote and informal testing methods are steadily becoming popular options to reduce costs while still getting real designs in front of real users. These tools can be strategically used throughout the definition (discovery), design, and development of a project to gain the most insight, even with limited time and on a small budget.

During Requirements Gathering

Talking to users about what features and functionality resonate most can help inform decisions on how to prioritize requirements. The most obvious method is simply picking up the phone or conducting user interviews users face-to-face. Recruitment of these users can take many forms—sometimes clients will even have a list of engaged users for you to work with. If you aren’t so lucky, Ethnio is a good product for recruiting users via a web-based intercept on a live site. Ethnio enables you to set up a screener, collect contact information, and provide incentives to potential recruits. Having a real conversation with the participants is ideal, but an online survey tool like Survey Monkey is a quick and cost-effective alternative to gather quantitative data across large sample sizes.

During Content Development

Card sorting and tree testing exercises help to evolve content categories and develop a site’s information architecture. If your project budget doesn’t allow you to recruit users and run these activities in person, you can still find users to participate on the web using tools like Optimal Sort and Tree Jack.

During Design

The evolution of the design process at Happy Cog has given rise to the creation of HTML wireframes to more efficiently document interaction design, content strategy, and information architecture across a range of screen sizes. These interactive wireframes not only serve as a design tool, but also are instantly-testable artifacts that require a minimal amount of setup before they are ready to be put in front of real users. Depending on the project, there are a few main ways you could gather data:

1. In-person Testing

Testing in person gives moderators the ability to physically observe participants’ reactions. A lot of information can be gathered from physical reactions, especially on mobile or touch devices where those reactions would be lost with remote testing. Recently, at Happy Cog, we went to a restaurant and informally tested a client’s site on the iPhone. We captured these sessions using the the UX Recorder app which captures gestures, audio, and front-facing video. It took all of three hours to complete, we gave each participant a voucher for free guacamole, and we learned a few simple things we could do to improve the responsive nature of the site.

If you’re conducting an in-person test on a laptop, it’s easy to record these sessions for later reference using a tool like Clearleft’s Silverback. It captures screen interactions, webcam video, and audio of a test session. Pro tip: setting up the test machine with screensharing software like Join.me allows other stakeholders to remotely observe the live test sessions in real time.

2. Remote Testing

Remote testing removes the barrier of having to be in the same geographic region as the participants. A tool like Ethnio can work well for recruiting for this type of test because it allows for recruitment across a large geographic area. To remove as many technical barriers as possible, we’ve preferred calling participants on the phone, hosting a web-based, screen-sharing session like Join.me, and giving users mouse and keyboard control.

3. Testing Concepts or Mockups

Occasionally, there may be a need to get design mockups or concepts in front of an external audience. Using similar remote and in-person methods as described above combined with a tool like InVision, designers can easily add in-browser interactivity to static design comps and put them in front of users.

Be Prepared

Not all tools or testing methodologies are right for every project. I am constantly adapting my testing toolkit as new tools become available and our design process evolves. Regardless of which type of test you conduct, it is important to set expectations with stakeholders.

A good test plan answers:

Why are you conducting the test?

What you are measuring?

Who is participating, and what are their incentives?

What methodology is being employed?

What devices are being tested?

What tasks are being tested?

What happens after the test is over?

Similarly, how you engage with test participants during the sessions can greatly affect the outcome of your test. Having a script that dictates how to describe specific tasks to participants can help create uniformity across testing sessions. Permitting yourself room to deviate from the script when participants behave unexpectedly can help surface the reasons behind potentially-overlooked usability errors.

Time has taught me the real value of user testing and has changed my perception of what is possible with a few hours and a small budget. Maybe one of these methods will help your team incorporate testing into your next project, even if you didn’t anticipate having the resources to do so. Are there any other tools you use for user testing? Let us know in the comments.

]]>TopicsUser TestingUsabilityResearchDesignThu, 23 May 2013 15:44 GMTIt’s Alive: Prototyping in the Browserhttps://cognition.happycog.com/article/its-alive-prototyping-in-the-browser
Patrick Marsceillhttps://cognition.happycog.com/article/its-alive-prototyping-in-the-browser#id:112#date:15:44In 1998, I built my first website. I hadn’t gone to college yet, and my professional goals had little to do with pursuing web design and a lot to do with playing in a rock band. While my peers were mowing lawns, washing cars, and frying things, I was curiously learning about HTML and attempting to share my efforts with the world. As my skills got sharper, I quickly realized that there were businesses out there that would actually pay me to do this… and it certainly beat having to get an afterschool job.

My career, the Internet, and their relationship to each other have all evolved significantly since 1998. As I grew into my role as a designer, I spent much of my time designing the page-level interactions of a web project in the form of wireframes. Front-end technology and mobile devices have since become much more advanced, and the web is no longer served on one screen size or one type of device. Now, documenting these interactions through a robust wireframe document is no longer an effective or valuable use of time.

I strive for my design artifacts to feel close to the product that I am designing—something I can easily test and something upon which different collaborators can painlessly iterate. Being able to design page-level interactions in a way that enables immediate trial and reaction is now a must. I’ve tried WYSIWYGHTML editors, web-based mock-up tools, and even desktop software specifically designed for prototyping to create these artifacts. I struggled to find a piece of software that had the right balance of features and flexibility, and after repeatedly allowing the limitations of these tools to constrain my designs, I decided to seek out another solution.

Design is the tool. Browsers are the medium.

We design sites, but what we build ultimately lives in a browser to be accessed on a myriad of different devices. I see this as an opportunity to treat the browser as a medium instead of strictly as a framing mechanism. We can take advantage of the browser’s unique characteristics early in the design process by testing and iterating on things like flexible width and height, horizontal and vertical scrolling, mouse/touch events, and media queries.

The rise of front-end frameworks like Twitter Bootstrap, HTML5 Boilerplate, and Zurb’s Foundation helped renew my passion for front-end development. I tinkered with a number of these frameworks and realized that building prototypes using my old friends HTML, CSS, and JavaScript was actually more efficient, easier for clients to understand, instantly testable, and more valuable for my project team than creating a robust deck of wireframes. I also found that hand-coding my prototypes afforded me infinitely more flexibility than wrestling with prototyping software.

A prototyping method

Building something real, testing it, and iterating on it isn’t a new concept. The “way it should be-ness,” a phrase coined by Charles and Ray Eames, expresses when a design works so well its very existence is secondary to the user’s purpose. To ultimately achieve this quality requires a trial of the realized design in some form. At Happy Cog, the iterative prototyping process described below aims to create that form.

Start broad, then refine.

Before one letter of HTML is written, it’s important to have an idea of what the entire system will look like even at a very broad level; it’s nearly impossible to accurately define “pages” before knowing their contents, so I like to collaboratively sketch key features and establish key pieces of content with project team members. These features can be defined in a requirements document, through a design workshop, or maybe just evolve organically. Wherever their origin, exploring and documenting these components is essential before (and throughout) the construction of a prototype.

Get setup to build, collaborate, and re-build.

There are several ways you can set up your system to construct and iterate on your own prototypes. If you’re comfortable in the command-line, Ruby, Git, and coding in text editors, these tools might serve you well:

Beanstalk – At Happy Cog, we use this as the version control system for most of our production code, but it also works well if you have multiple people collaborating on a single prototype.

The Serve gem – Serve is a lightweight, local web server that allows us to use partials and layouts (just like in Rails!). With Serve, we can create and share modules across pages, establish basic page logic, and export a static version of our site in plain old HTML for easy hosting/sharing with clients.

Sass & Compass – Allison Wagner wrote a fantastic post about the benefits of using a pre-processor like Sass. Additionally, I like to prototype with Compass (a framework for Sass), because it comes preloaded with common design patterns and speeds up development time.

Susy – Susy is a responsive grid framework for Compass. It lets a designer easily establish a grid system and include breakpoints in a semantic-friendly way.

Create a feedback loop.

After I present work to peers and clients, I catalog and prioritize feedback from all channels in one place to help me focus on delivering the next iteration of the design while keeping the project in-scope and on budget. I create a master spreadsheet of items to address and flag those that are at risk of not being incorporated into the next iteration. This way, the entire team has a transparent view of how the prototype is progressing and what the potential blockers are.

Like any process, there is always room for improvement. This is only the beginning of a greater collaboration between design and development. It yields a higher-quality product, because there is more opportunity to refine what is being built. How does increasing the areas of overlap between these disciplines shape your process?