Day One at An Event Apart DC

An Event Apart kicked off yesterday morning in Washington DC, and as usual, it has the web design community all aflutter! UX Booth is no exception to that excitement. This year, front end developer Karen Kitchens is attending and bringing daily recaps of the talks she attends.

An Event Apart DC has been a real treat so far. Below are some of the big takeaways from each of the talks I attended, as well as some solid next steps for folks who’d like to incorporate those takeaways into their own processes. Be sure to check back tomorrow and the day after for additional day recaps! Can’t wait until tomorrow!

From Research to Redesign: an Unexpected Journey, by Jeffrey Zeldman

We’re not just designing brands; we’re designing brand experiences. Everything we do needs to be pro-user and not anti-user. When we’re researching competition in the marketplace, we need to look at sites and examine them for them for their stance toward the user. Zeldman points out that there’s a lot of borrowing of techniques in the web world, but one definitely wants to make sure that they’re not mimicking patterns that hurt users.

Some developers and designers rely on others to research for them, but I have felt like Zeldman does, that doing the research myself makes the act of decision making easier and more meaningful. Zeldman notes that each page on the site needs to convey the brand (not just homepage). After all—a user’s first experience with your brand/site could be through an obscure product detail page that you had not put much thought into.

Next steps for the rest of us: Take the time and do the research yourself!

Designing for Understanding, by Stephanie Hay

Stephanie Hay has some wonderful lessons from creating A.I. experiences with Capital One. Her work with Alexa, and then a Capital One A.I. called Eno, provided some very interesting results for those creating these types of interactions. Her products needed to incorporate “natural language,” but with context specific to the interaction. For Alexa, people spoke to the A.I.; for Eno, people texted. Real conversations lead to better understanding, but the conversations between humans and A.I. is not one-size-fits all, and requires extensive prototyping.

Prototyping should not scare anyone off, however, because it can be done with simple tools like Google Docs. We should prototype until understanding is achieved. Instead of explaining how a product works, explain what the product is, and why it’s great; it’s only then that you get into the nitty gritty.

Next steps for the rest of us: Get rid of Lorem Ipsum! Start asking people:

• Is there anything you love about [a particular experience]?
• Is there anything you hate about [a particular experience]?

Prototyping: the Scientific Method of Business, by Daniel Burka

Daniel Burka wants to bring the scientific method to design. He recommends having a question in mind, and then a mix-and-match of the best hypotheses that the individuals in your group come up with. Then, create sprints you can test in a laboratory environment. He offered a great (and silly) example question: If a robot does a cute dance for users, will they be charmed and want to continue engaging with that robot?

Next steps for the rest of us: Start writing tests. It’s perfectly okay for your hypotheses to be wrong. Watch people use your products live.

Should Designers? by Dan Mall

There’s a truth in web design: we’re probably going to end up with similar headers and footers to everyone else. Designers shouldn’t spend that much time in these areas, and rather focus on the aspects of the site that are unique to that particular site. Ask “What is different?” “What need special attention?” And then put the focus there.

Next steps for the rest of us: Look for areas that set your sites apart from others.

New CSS Layout Meets the Real World, by Rachel Andrew

We really don’t want to be coding for the past. Feature Queries are like media queries but for growers that support a particular css feature. Using @support is a great method for future proofing, because once a browser supports the queries, it will always support it. You can use this for any spec that hasn’t made full support yet, not just CSS Grids.

Next steps for the rest of us: update auto-prefixer and start using @support for Feature Queries.

Designing with Grid, by Jen Simmons

While Rachel makes the case for how to implement CSS grids with Fallbacks, Jen Simmons makes the case for why you should use CSS grids. Simmons declares the one thing that I’ve been afraid to say, and that is that layout is hard to do with CSS. Using famous modern artists as examples, she thinks about ways to reconfigure their work through the lens of different viewports.

Next steps for the rest of us: Stop ignoring the Viewport and use Mozilla’s latest code inspector to work with CSS Grids.

Stay tuned for day 2

Be sure to check back tomorrow for my account of Day 2 here in Washington DC at the ever-exciting An Event Apart!