TL;DR

I’ve started a scholarship fund for students in my home town of Fitchburg, MA. It’s called the Fitchburg Design Fund. Put money in it, plz:
https://cfncm.org/donate?fn=fitchburg-design-fund

Below is more info that’ll hopefully make you comfortable with donating your hard-earned money. If you have questions after reading, please ask them. This is a new thing for me, so I welcome your feedback as it can only make this more successful. Similarly, beyond ensuring there wasn’t already a scholarship quite like this one, I’ve yet to plug into any of the various arts & culture organizations that exist in the Fitchburg area — If you belong to any such groups and you think there’s some way for us to work together, please let me know.

This scholarship is for a Fitchburg High student planning to go to Fitchburg State or MWCC to study design. We’ll select our first recipient this coming school year, in April 2022. This student will receive $1,000 to use at their discretion towards the cost of college. The fund is managed by the Community Foundation of North Central Massachusetts. The Scholarship Committee is me + FHS guidance counselors.

You can read more about the scholarship requirements, or apply, here: https://www.rollstonepress.com/scholarship

Why?

I was introduced to graphic design at Fitchburg High School, through the graphic design electives they offered and the opportunities to practice it at school; designing our bus passes, our yearbook cover, and (sigh) the clip art-esque FATV logo still used today. I was lucky to have been able to continue my education right in my local area, first with an A.S. in Computer Graphic Design from MWCC, then a B.S. in Communications Media from Fitchburg State. The Fitchburg State program concluded with an internship in Boston. When it came time to find a job, I was more than comfortable looking in Boston, thanks to that internship. I’ve been gainfully employed as a designer at a Boston-based company ever since. In addition to the local educational & public transit infrastructure that made this path so accessible to me, I had help along the way from individual people who invested their time & energy into my success. It’s time for me to pay that forward.

The kind of design I do now is focused on identifying pain points in user experiences and finding ways to remove those pain points. I want to spend some time doing that for this particular educational/career path. To date, this has mostly been my involvement on MWCC’s advisory board, where since 2013 I’ve provided feedback on their design curriculum as part of their annual review. Since moving back to Fitchburg in August 2020, I’ve been looking at ways to do more, and for opportunities that can have an impact earlier in the student’s journey. This scholarship allows me to do that.

Right now I have 3 goals for this scholarship, and as you might guess, there are ways you can help.

Goal 1: Actually have at least one recipient every year.

Maybe this won’t be a challenge…but it could be. We’re not talking about a huge number of students — the graduating students from one high school, that specifically want to study design, at one of these two specific colleges. But I want this to have a local impact, so this is where we’re starting. And I want to increase the number of students considering careers in design because I think it is an infinitely flexible skillset that can be applied in a range of industries, and I love it.

I’ll be working towards this goal personally by going into FHS design classes to get high schoolers hyped about design and applying to this scholarship. If you have any advice, or are also a designer who wants to get in front of high schoolers and sing the praises of design, let me know! Comment here, DM me, text me, whatever.

Goal 2: Convert this fund into an endowment so it lasts forever.

Right now, this fund has an account balance that we’ll draw against when we award the scholarship, and we’ll need to keep adding cash back in to keep the scholarship going. But as an endowed fund the balance would be invested (by CFNCM) and pay out the scholarship using the annual gains while leaving the principal intact, so the scholarship lasts forever! To award $1k annually using this approach, we need this fund to reach ~$23k. We’re at $10k now and we’re just starting, so this is doable! You can help us reach this goal by donating here: https://cfncm.org/donate?fn=fitchburg-design-fund

Goal 3: Perpetually grow the scholarship through the sale of goods.

This is the least fleshed-out part at the moment, but you may have noticed the scholarship application is hosted at “Rollstone Press.” This is a currently-very-empty website I’ve made where I’d love to eventually sell design work, with profits going towards the scholarship fund. If successful, there’s no limit on the scale this fund could reach. It’s exciting to imagine that a few decades out, this fund could be providing a full ride design scholarship!

I’m still working out the specifics of the store, but if you’re a designer and would like to be involved, let me know. Contributing designers will of course be compensated; you deserve it, and it’s important that prospective design students know that you were paid to be a designer.

That’s basically it.

So that’s what we’ll try to accomplish with this scholarship: help students from my home town pursue a design degree at one of our local colleges. Suffice to say I think this is worth doing, and hope you do too.

— Dan
https://twitter.com/dlac

First, if you’ve never before seen this “Minimum Viable Product” illustration before…

…then I highly recommend checking out this article by Henrik Kniberg.

TL;DR

An MVP is the simplest version of your product that allows you to learn about the business viability of the product. The goal is to determine whether or not the problem you’re trying to solve is worthwhile as early as possible, with limited time and resources invested. The tricky part can be identifying the core functionality required to provide value to your users.

In the illustration, the product is “a mode of transportation.” A skateboard, while not as snazzy as a car, still qualifies as a mode of transportation. You’re going to learn more about what your potential customers expect from a mode of transportation by shipping the skateboard than you would shipping just a tire, because it’s something that they can still actually use to get from point A to point B. They’ll certainly run into limitations, but the feedback you receive as a result will make your product better over time. A single car tire is useless, to both you and the user.

Applying this to an e-commerce scenario at Wayfair

A few years ago, my team was asked to explore opportunities to address a pretty typical problem in e-commerce, presented here as a user story:

“As a customer interested in this product, I want to compare it to similar products so that I can better understand if this one is right for me.”

Sounds straightforward enough, right? We do this all the time as shoppers! I’m sure this even conjures up thoughts of comparison tables and widgets you may have encountered when shopping online. There was definitely a conversation (or five) about building one of those comparison tools right from the get-go. But was this actually our “skateboard”?

Once we started diving into the specific user needs that e-commerce features like this one are trying to address, and the technical challenges of actually delivering a comparison feature like this, we found there were plenty of opportunities to keep development lean for our MVP.

User Needs

For this project, we sent out a survey that garnered about 150 responses, and we conducted in-person interviews with 5 shoppers that were actively looking to make a purchase. We recruited shoppers looking for items with varying levels of complexity and technical requirements — we sell everything from throw pillows to refrigerators on Wayfair, so ensuring that breadth was represented in our conversations was important. In addition, we reviewed heuristic guidelines from the UX consulting firm Nielsen Norman Group.

Whether you define the above amount of research as “lean” or not will depend on the resources available to you, but from our perspective, a day’s worth of interviews and a survey were not a huge lift. And, per usual, the user research has paid for itself, with interest.

We learned a lot, but the following highlights are those that are most relevant to the path we took for our MVP.

The major takeaways

1. NNG’s heuristic guidelines tell us comparison is best done with a small set of products. It’s not a shock that comparing 5 things to one another is easier than comparing 30.
2. No matter the product type, folks are most interested in comparing just a few characteristics. The image, price, reviews, basic specs (weight and size), and product name are the key drivers for comparison.
3. For most users, those “key drivers” don’t change much when the product is more technical. This finding busted an assumption we’d initially made: if the product is really technical, then comparing those tech specs is important, right? Not necessarily. Most interviewees mentioned increased nervousness when all the technical information is highlighted. They’d be more likely to seek recommendations from friends, families, or experts.

In other words, people don’t want to comparison shop; they want to see comparable products. Beyond that, they don’t want comparable products; they want the product that’s right for them. They’re usually going to use the tools they’re already familiar with to find it rather than picking up a new one. It’s not shocking that the majority of the information participants identified as key drivers are on a standard product card:

This might seem obvious if you’re familiar with Jobs-To-Be-Done (which I wasn’t at the time). It’s also obvious if you’ve ever, say, helped a relative pick out a new computer:

You start off talking about the difference in RAM and graphics performance among the most popular options before you notice that their eyes have glazed over. You take a step back and ask a question like “What are you going to use it for?” and, taking their answer into consideration, you make a more tailored recommendation — which they trust, because after all, you’re the expert.

Technical Challenges

The following is directly from Nielsen Norman Group’s article on Comparison Tables…

The biggest problem with most comparison tables isn’t a design problem, it’s a content problem. When attribute information is missing, incomplete, or inconsistent across similar offerings, otherwise handy comparison tables quickly become useless. This is especially problematic for dynamic comparison tables, when you’re dealing with many offerings with slightly different metadata available.

After some investigation by our engineering team it was clear that we were going to have similar content issues to those depicted above. While there were some product departments where we were more confident the content would be robust, “cleaning up” the catalog overall posed a significant challenge. Knowing this was a helpful constraint when considering our options.

So our user story had largely been validated through our research, and specifically we learned our customers…

1. Find comparison shopping overwhelming given the breadth of our catalog.
2. Are usually comparing products using fairly basic info.
3. Are keen on receiving recommendations.

Which was fortunate, since from a technical perspective it would be no small feat to provide a robust content-heavy comparison experience.

How we defined success

If from a customer perspective the goal is to find the right product, then what are appropriate KPIs? We defined a successful MVP as one that achieved the following:

Improved Add-to-Cart Rate: Customers adding items to cart more often would be a good indication that we’re helping them find products they’d consider purchasing.

Improved Conversion Rate: It’s not enough to have customers add to their cart, as they tend to hold items in their cart while they continue to evaluate the product. If our goal is to provide an experience that aids in evaluation, then we should see more folks actually purchasing products.

Let’s build a skateboard

So we believed that a dedicated tool might be more work than the typical customer is willing to put into this task, and a full-blown comparison table would turn out pretty wonky. For these reasons, we proposed something completely different than we originally had in mind.

Let’s try something on the product detail page, instead of the product listing page.

Then, we can present the customer with a small set of products based on the product they’re looking at rather than requiring them to “select” a product (or several) to compare. Less work for them, less work for us.

Let’s stick with product cards instead of a table for now.

Most customers aren’t clamoring for more information than what exists on a product card anyway. If we’re not including a bunch of extra specs, does it need to be a table at all? Let’s say “no” for now and leverage an existing component.

With those two elements in mind, we ran an A/B test.

We swapped this:

for this:

Ta-da.

We substituted an existing “Customers Also Viewed” product carousel for one that…

1. Explicitly said ‘Compare Similar Items.’*
2. Had just 4 product recommendations, instead of 30.
3. Included the product the customer was currently on, so they could see it side-by-side with our recommendations.
4. Included an “Add to Cart” button, in case they are ready to purchase after comparing.

*The algorithm we were using for "Customers Also Viewed” already did a decent job of presenting similar products, and while improving it was something we identified as a long-term opportunity it was not something we included in our MVP.

That’s it..?

For “comparison shopping” as an initiative? Absolutely not! Since this MVP, we’ve tested and launched improvements to this feature and other totally new experiences on site.

But for our MVP test? Yep! And it was successful!

Our core metrics (ATC & CR) improved, along with…

• Page Performance: Ditching 20+ product cards will have that effect.
• Average Order Value: If customers are confident they’re evaluating otherwise-comparable products, maybe they’re willing to spend a little more for, say, a higher-priced one with better reviews? Or a higher-priced one that’s got a deeper discount? More to explore there, but not a bad result either way!

Wrap Up

We learned a bunch along the way about what some customers might want in some scenarios. But in determining the scope of our MVP, we had to balance those needs with the assessment that, in “red routes” parlance, there was value to be found in making some fairly straightforward improvements to experiences most users have, most of the time. By focusing on MVP, we took a successful first step, and we’ll continue to improve the experience over time!

An “MVP” Design Story was originally published in Wayfair Experience Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Wayfair continues to build out our growing design org, we’ve been crossing t’s and dotting i’s on our training materials for entry-level and experienced designers alike. We thought it might be useful to publish these guides to Medium as well!

What are annotations?

Annotations are brief, written explanations provided with design deliverables in order to define & describe aspects of the design. They’re paired with numbered labels on the design itself to visually map each description to the relevant part of the design.

The primary purpose of annotations are to explain aspects of the design that the recipient may not otherwise perceive, understand, or account for during implementation. They may be used differently from project to project, but they should always be serving this goal.

Different from project to project…?

Annotations aren’t always paired with the same kind of deliverable.

We often hear about them in the context of wireframes, but that’s sort of just a byproduct of their historical usage. Simply put: if writing & distributing some notes with your design will help your cross-functional partners better understand it, then have at it! You could be handing off a user flow annotated to explain certain happy paths & edge cases, wireframes annotated to explain functionality or conditional states, or high-fidelity mocks of static pages that use annotations to convey specific style requirements and asset locations. All of these are completely valid uses for annotations.

They’re not always necessary.

All those examples of deliverables I just mentioned? You can also have projects where these same deliverables do not require annotations at all. More on that below in the “When it’s not useful” section.

The format and delivery of annotations can change from project to project.

If they’re short & sweet and light on technical specifics, you may want to just include them right alongside the visuals, baked right into the Invision, PDF, etc. If they’re verbose & very technical, you may be better off moving them into a separate document. Having those numbered labels on the design that correspond to the annotations provides this kind of flexibility.

When during the design process should you annotate?

While waiting until designs have been 100% approved is the ideal (so you don’t end up having to revise your annotations based on changes to the design), that’s not always possible due to parallel workflows, and sometimes there can be a benefit to annotating a little bit earlier in the process.

When your deliverable is roughly 80% ‘complete’, that’s a good time to consider annotating. Prior to that, designs may be too ‘subject to change’ to make annotating valuable, but once you’re in the final rounds of revision, annotations start being really helpful.

…Why 80%?

While you should certainly be communicating with stakeholders and developers throughout the entire design process, sometimes this 80% mark is the point at which your conversations will move over to email or slack and other business stakeholders get looped in. Written explanations can help expedite those conversations by providing context to a broader distribution list, without requiring additional meetings.

In my own experience, this also tends to be the point at which my product manager and developer(s) start to really think about the design as a collection of discrete, bite-sized engineering tickets. If they’re able to start referring to “Annotations 1.1–1.3” when scoping and entering those tickets, that makes everyone’s lives a lot easier.

When are annotations useful?

If your project meets any of the following criteria, consider annotating your deliverables…

There are elements of the design that are not totally obvious from the visuals alone.

• Hidden content — What else is in that dropdown?
• Interactivity — What’s that button/link do?
• Unrepresented constraints — Is there a max-width on this card/field/button?
• Conditional stuff — Are some elements different based on user type, product type, user interaction, etc?

The project itself is a non-trivial effort to build.

• Are we talking about a new feature?
• Are multiple developers working on this?

You don’t know exactly who the audience for your deliverables will be.

• Don’t know exactly which developers will be working on it?
• Does your PM need buy-in from Merch/Category folks with whom you haven’t had much interaction?

When aren’t they useful?

While annotations are helpful in providing clarity and definition to an otherwise complex or ambiguous project, some projects start out…pretty clear and well-defined! If we’re talking about a fairly minor ticket being implemented by a developer with whom you work really closely, and you’ve got zero stakeholders outside your immediate team, then feel free to keep it lean and skip the annotations.

A quick step-by-step guide to annotating…

Step 1: Determine what format you’ll be using for your annotations

Are you going to put ’em right on your Sketch artboard? In a separate Google Doc? The world is your oyster, and you can change your mind later if you need to.

Step 2: Determine what elements you’ll be providing annotations for, and label them in your design.

These should be the elements that fit the criteria mentioned above in “When are annotations useful?”

Step 3: Write out your annotations!

They should contain…

• An ID that corresponds to the label you placed on the design.
• A succinct title that confirms at a glance that this is the correct annotation (i.e “Password Field” for the password field annotation)
• A brief description of: functionality, or user expectations, or style requirements, etc.
• When presenting alongside the design: nearly every article on the internet will put them/advise you to put them on the right. I like ’em on the left. You decide.

Step 4: Make them available to the intended audience!

If you’re using a document separate from the designs to deliver annotations, there’s always a chance that document doesn’t survive the journey once folks start passing around your work; whenever possible provide a hotspot, link, etc to your annotations from within your design deliverables.

Things to watch out for…

Writing annotations is NOT a substitute for speaking with your developers.

In fact, you’d be well-served by using them as the agenda for a touch-base with your cross-functional team, where you walk through the annotations in person and solicit questions & feedback. With really granular, technical annotations (what tend to be referred to as ‘functional specifications’) you may see these copy/pasted directly as the acceptance criteria on engineering tickets, so make sure everyone is aligned as early as possible!

Developer says: “Oh, I didn’t read the annotations.”

As sure as the sun will rise tomorrow, you will be asked questions that you explicitly addressed in your annotations.

First: Relax. It happens. We’re all human.

Second, keep that link handy and respond with the annotations, citing the specific label they can refer to for their answer.

At Wayfair, we communicate a lot on Slack and for larger initiatives, we’ll have a project-specific channel. That’s a great place to “pin” the annotations and other design deliverables!

Frequently Asked Questions…

1. What kind of stuff should I include in annotations? How do I avoid getting too specific or being too vague?

The answer for both of these is talk to your developer; make sure that you two are fully aligned on what level of specificity is appropriate, and write no more than that. Knowing your audience is important and anticipating the questions they may have is a great way to determine what needs to be annotated, but as product designers, we tend to work with a bunch of different teams and “too specific” / “too vague” will vary from person to person. If you have to pick one person for whom the annotations are 100% crystal clear, make that your developer.

2. What if stuff changes during development? Do I have to go back and update these?

First: annotations, just like your other deliverables, should have a date on them somewhere that conveys when they were last updated. Beyond that, if you want to make minor changes after hand-off, do it up. It’s great having a 100% accurate set of annotations and designs to refer back to, whether it’s to the benefit of someone down the road working on the next version/iteration of the project, or simply to act as a point of reference for the expected in-production functionality. But if it gets unwieldy to maintain because a lot of stuff is changing in development…that’s what the “last updated:” date is ultimately there for.

That said: if this is happening a lot, it’s worth discussing in your scrum team’s retro. Alarm bells should go off if designs & annotations are going stale before development has even finished. There are a bunch of different reasons this happens: edge cases get missed, the scope of the project gets trimmed down, etc. It happens. Whatever the reason, it’s a learning opportunity, so make sure you talk about it.

3. When you say “annotate your deliverables”….which deliverables are you talking about? I have multiple. Do I annotate them ALL? That seems stupid.

Primarily, this is meant for whatever deliverable your engineer is referring to during development. But it’s up to you; maybe the user flow you made is just a stepping stone on the way to full-on designs BUT you know it’s going to get passed around to every stakeholder under the sun for feedback — probably worth annotating it if you can provide some additional context by doing so!

Conclusion

Hopefully this article sheds some light on the value of providing annotations and gives you some insight on how to make use of them in your own work!

If you found this useful, or if you’ve got your own tips & tricks, let’s chat in the comments!

Design Basics: Annotating Your Work was originally published in Wayfair Experience Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Treat this like product development: identify your MVP and test it.

There are hundreds of articles & posts across the internet on the topics of Responsive and Adaptive Web Design —here are just some of them. The gist seems to be, “there are pros and cons to each!” and while some folks might go so far as to advocate one approach (usually Responsive), most will abstain, opting to simply stress that it’s a very important decision.

I’m throwing one more point of view onto the pile, that stems from the following observation:

Increasingly, Web Design/Development looks like Product Design/Development— which makes sense, as apps and sites are products in their own right. But why, then, are there topics — like this “Responsive VS Adaptive” one — that we don’t seem to discuss with the same vocabulary Product Designers bring to every other problem space?

The “Responsive vs Adaptive design” debate is often framed as a choice between…

Development simplicity that may have some unintended consequences for users… so be careful!

Or…

Development complexity that might serve users better more often, but has its own drawbacks…so be careful!

But product development constantly navigates the space between simplicity & complexity. While the vocabulary we use in that realm — defining an MVP, iterating over time through testing, etc — sort of assumes you have the ability to move between both ends of the spectrum over time, no one seems to discuss web layout this way. Instead, you’ll find plenty of posts (including some of the examples above) that talk about choosing between Responsive & Adaptive as a philosophical decision. Some say that one approach (Responsive) is more future proof than the other. I don’t know about you, but I have a hard time imagining anything as “future proof.” That kind of talk tends to lead to wonky ‘conventional wisdom’ and blind spots. So let’s talk about Web Design as if it was Product Design because, surprise, it is.

Do you A/B test your work? Let’s talk about THAT instead!

Sigh. I wish “A/B testing” was as popular a topic as “Responsive Web Design,” but at least we’re trending in the right direction.

Let’s bridge this gap together! For the sake of not bloating this post with an A/B testing explainer, check this article out if you’re not already familiar with the topic. With that said, I do want to briefly emphasize one aspect of testing & leveraging data in design…

What are your goals? How do you measure progress?

Before you design anything at all, you should have a firm understanding of your goal — which should ultimately be about helping your users accomplish their goal. And you should know what achieving that goal looks like in terms of measurable actions they can take on your site. Those are your “key performance indicators.”

For example: one goal for an ecommerce site is to ensure that, for users who are navigating to products, we’re making it easy for them to evaluate the product, and if it’s right for them, we make it easy to add the product to their cart. As a result, we often talk about the “add-to-cart rate” — of those customers who have an opportunity to add a product to their cart, what % actually do? — as a primary KPI.

It’s not enough to rely on your cross-functional partners to tell you that an A/B test “won” or “lost.” You should understand how success was defined for the test. Knowing your KPIs, how they relate to user needs, and how performance differs across various screen sizes and user segments, is ultimately more valuable to your business, and to you as a designer, than knowing whether to choose “responsive” or “adaptive” when kicking off a project. To that end, I’m going to advocate for a specific answer to that question…

Your MVP should be Responsive

Cutting to the chase: you should design, develop, and test across all device types — phone, tablet, & desktop — in tandem, with an emphasis on providing a responsive solution whenever possible. What I mean when I say “responsive” is: as often as possible, plan on letting your elements grow or shrink to fill the space as needed, and avoid decisions that rely on the site needing to react to information about the user’s environment in order to provide optimized content.

“Responsive” should not mean providing a lowest-common denominator solution. Avoid making something that sorta works everywhere, but isn’t great anywhere. It can be completely appropriate to designate a certain device & browser where your design works exceedingly well and plan for the design to ‘degrade gracefully’ on other devices, browsers, and screen sizes.

Determine what your product’s red routes are, what platform your users will predominantly be using, and focus on this for your MVP. You need to get something out in the world so you can learn through testing and establish a baseline for all platforms.

While HTML/CSS specifications are constantly getting better and the possibilities for “Responsive” get more robust, there are plenty of scenarios where you’ll find that it only gets you so far. There will almost certainly be opportunities to create even better experiences for certain devices or screen sizes, even if that means more complex product development.

But these more complex experiences should, whenever possible, be the result of a responsive-first design approach paired with a multi-platform A/B testing strategy, and not just the result of you, dear designer, thinking that mobile and desktop inherently require divergent solutions.

Maybe you think that a slavish devotion to responsive design “leaves money on the table” — I don’t necessarily disagree, I’m just asking you to show me how much, because it also costs money when you add development complexity.

Then test the “adaptive” stuff.

From a development perspective, this can mean some of the more straightforward stuff like media queries to redefine some CSS values to better suit your content at particular screen sizes, or it could mean using some javascript in order to learn more about the user and serve a more dramatically modified experience. This whole suite of solutions is broadly defined as “adaptive web design,” though many posts will get even more specific, citing six breakpoints you should be designing for.

Rachel Andrew advises, in this Smashing Magazine article, “don’t target devices, add breakpoints when the design breaks” — I like this! The perceived complexity of an “adaptive design” comes from that “six distinct breakpoints” approach. Let’s ditch that. Instead, start with responsive and only go about building in adaptive fixes when the design “breaks.” I would add that you should really try to rely on both qualitative & quantitative data to define what “broken” means. “Not delightful” ≠ “broken.” Are there red flags from usability testing? When looking at your KPIs, are there meaningful differences across breakpoints and devices? If so, these are a pretty defensible reasons to start exploring adaptive designs.

“Progressive Enhancement”

Progressive Enhancement is where you start to push into the kind of functionality that is specifically enabled by technological differences across devices & browsers. Stuff gets complicated to build, QA, & maintain, so everything I’ve emphasized up to this point regarding A/B testing goes double, but the upside can be transformational for your business. Just have a very clear understanding of how you define success before you go adding an “Apple Pay” button to your site.

Why design, develop & test this way?

Like they say, non-responsive design can be expensive:

• There’s an opportunity cost to just assuming the necessity of non-responsive, platform-specific differentiation in a design: what work needs to wait while you spend time developing multiple solutions in order to test one hypothesis?
• There’s recurring design, engineering and QA cost to maintaining these differentiations over the long-term.
• There’s an SEO cost, though I think this is more specific to those sites that have separate “mobile” and “full site” implementations with separate site indexes.

Choosing to go “responsive” at the outset should never be used as a reason to avoid exploring adaptive optimizations & progressive enhancements in the future, but if your design includes those optimizations from the get-go, you are incurring the above costs without having demonstrated the business value of doing so.

On the other hand, if you test a responsive solution first, you may find…

• The test “loses” on ALL platforms: I’m sorry to hear that. But no worries, you’ve simply accelerated your learnings by cutting down on the time spent getting that version out — less hours on design, engineering, QA, data analysis, etc. If you end up back at the drawing board entirely, you’ll appreciate that you didn’t spend time making six super-special breakpoint-targeting versions of your design.
• The test “wins” on all platforms: Congrats, you’ve got a responsive solution that adds value to the business! If you still think there’s non-responsive optimization to be done to maximize value, you can prioritize this appropriately knowing you’ve set yourself up for a better follow-up test that will more accurately reflect that specific hypothesis.
• The test “wins” on some platforms & “loses” on others: You’ve got some options! Leveraging learnings from the first test, and with some measure of validation that you’re on the right track, you can try again for a responsive solution. Or maybe what you’ve learned in the initial test has you thinking you’ll need to produce a non-responsive solution in order to “win” on both platforms. At any rate, you may have the option (and incentive, based on test results) of launching a platform-specific solution to the “winning” platform in the meantime!

Choosing between web design approaches is NOT a philosophical decision.

There are decisions you make that provide value to your users and decisions that don’t. There are costs that are incurred and/or benefits to be gained with each of those decisions. Make use of Design Thinking and Business Intelligence to aid in this decision. Trust the process, and take those “VS” articles with a grain of salt, because only through conducting your own exploration and experimentation will you figure out what’s best for your users and your business.

Don’t debate Responsive VS Adaptive Design. was originally published in Wayfair Experience Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve ever been tasked with designing a new feature for a site/app/etc, you’ve likely had a stakeholder say to you something like…

“Here’s what [the market leader] does; let’s just do that.”

…which saved you a ton of time and effort, because you were able to just copy that design, skin it for your brand, and call it a day, right?

Well no, of course not. While there are benefits to looking at how competitors solve a problem, and there are certainly conventions that should be followed based on user expectations, there are some big problems with just copying someone else’s solution wholesale — for starters:

• You don’t know why the competitor built a feature the way they did, or how it’s performing for their users.
• You’re assuming that your users’ needs are identical, and that context doesn’t matter.

Simply put, in copying a competitor’s solution and skimping on due diligence, you’re abdicating your responsibility to your user. The following is a rough outline of what that ‘due diligence’ should look like.

Know your user and their needs.

The first step to performing successful competitor research is…performing successful user research.

If you lack a clear user problem, it’s easy for folks to define the goal of a project as “deliver our version of the competitor feature.” But once you have a well-defined user problem, it’s easier to see how any given competitor feature is just one possible solution. Folks will immediately start to see how solving the user problem could take many different shapes.

Once you have a well-defined user problem, it’s easy to see how any given competitor feature is just one possible solution

How do you uncover the user problem? Here are some of the ways we collect qualitative feedback directly from our users at Wayfair:

• User Interviews (both in-person and remote)
• Usability tests (both in-person and remote)
• User Surveys
• Focus Groups
• Card Sorting Activities

Here are just a few online resources on the subject of user research.

If you’re doing none of this today, don’t panic; there are some very lightweight, scrappy ways to get started. Once you’ve gotten your feet wet and your company sees the value of this kind of research, there are many ways to push this practice even further.

Define the competition

Build out your list of competitors — they’ll fall into two categories: direct competitors and indirect competitors. You can learn more about these categories (and competitor research in general) in Jaime Levy’s UX Strategy, but here’s a definition by way of example:

TripAdvisor and Airbnb are direct competitors. First and foremost, they’d like to be your preferred destination for booking the accommodations of your next trip. In trying to accomplish that, they’ve got ancillary services like offering tickets to events in the area and the ability to book reservations at local restaurants. These ancillary services make them indirect competitors with myriad other services like Yelp, OpenTable, Groupon, Foursquare, etc.

Your PM and business stakeholders will be helpful in compiling your competitor list — ask them who they see as the biggest players in the market and why.

I’d recommend keeping a shared list of as many competitors as you can think of, that all your designers and researchers have available to them, even if you’re not pulling the full list into a given research project. Depending on the initiative, you may find yourself re-prioritizing who is a direct or indirect competitor, and casting a wide net in building this initial list will save you time down the road.

Conduct the research

For any given research project, try to look at at least 10 competitors, with at least half of them being direct competitors. I tend to find more is better, but start with 10 and once you’ve worked out the kinks in your process, you can add more next time.

Open up a spreadsheet (I prefer Google Docs; Excel is…fine). The first column should be your list of competitors (hyperlinking these is helpful!), and each additional column should represent a specific feature or element you’re looking for.

You’ll see other approaches if you do some digging online, but my preferred method is to mark each cell as a fairly binary “yes” or “no,” for whether a feature is/isn’t present, and I’ll add comments to the cell with additional information I think will be important when I’m writing up my findings. This allows me to easily sort my sheet by certain variables when reviewing my findings. And since I’ve got some conditional formatting on my ‘yes’ and ‘no’ cells, it’s that much easier to pick up on correlations and/or dependencies between these variables.

Again, there are other ways to do this, but I’m a fan of this format—I find it better enables me to recognize the trends that emerge and is easier for others to get the gist of at-a-glance, but your mileage may vary. If you find an organizational format that works better for you, go nuts. The important thing is that you are capturing your observations on a spreadsheet that you (and others) can easily refer back to.

Fill your sheet out by visiting each competitor, and take full-page screenshots as you go (for websites, Awesome Screenshot is my preferred Chrome extension). Keep an open mind as you’re doing this; avoid honing in on just those elements you initially think are important and really spend some time on these sites. Every single time I’ve done this, I’ve noticed trends and patterns that require me to add additional columns to track elements I hadn’t initially considered (having those screenshots handy makes doubling back to fill out new columns a lot easier).

You’ll start to get a sense of how common particular solutions are*, and what their advantages and disadvantages are. Give yourself a full day to do this. You’ll often find you can go back to this same research for future projects, so don’t get too queasy about the time spent. And, by the way, this is one of the ways you become a credible subject matter expert in the eyes of your PM/business partners.

*Note: Remember that ‘common’ won’t always mean good, but you need to have some sense of what the conventional solutions are, since this has an impact on user expectations. Feel free to buck those conventions when it comes time to design — shoot for the stars! — but make sure you’re incorporating usability testing or other methods of ‘de-risking’ your solution.

Summarize your findings

Do not send this spreadsheet to your stakeholders and call it a day. Here’s the format I recommend, whether you’re sharing it in an email, Google Doc, PDF, Invision Board, epic poem, etc:

• Brief summary of the goal of this project and your findings — this should include the user problem you’ve all previously aligned on.
• Prioritized list of high-level takeaways
• Prioritized list of recommendations and next steps
• Notable findings (this is where you can sum up your spreadsheet as a list of stats, as needed)
• A link to the screenshots you collected (up to you how you organize them, but DO organize them)
• A link to your handy-dandy spreadsheet.

Present your findings

How you present your research is just as important as how you conduct it.

Your research won’t matter if your stakeholders don’t take it seriously. Building trust with your PM can take time, and how you present yourself and your work is a major factor in establishing your credibility. I’ve written about this a bit previously, and these are two great articles on the subject I highly recommend, but here are a few quick pointers:

To start, get this in front of the relevant audience at least a day before the meeting so they can review it at their own pace. This will make your meeting much more productive.

When you meet, I recommend covering the research in roughly the same order as your pre-read — and if everyone’s actually read your pre-read, all the better! You can dive into discussing what this solution might look like. In any case, avoid jumping right into those screenshots. Honestly, the less you have to lean on those, the better. As soon as there’s some kind of visual on the screen, you’ll find yourself competing for attention. They’re useful as a ‘case in point’ but should not occupy the bulk of your discussion.

As you cover your takeaways and recommendations, explain how they solve the user problem you all established at the outset of this project. This is your success criteria, not how much your solution looks like what the competitor is doing.

Conclusion

With any luck you’ve now got a rough idea for a solution that feels organic to your users’ needs, and it’s clear to all involved how your competitor research has informed it. If it improves upon the competitor feature your PM came to you with on day one, great! If it’s easier to implement because you’ve identified existing functionality on your site that can be leveraged to solve the user problem, even better. Lightweight engineering solutions are a surefire way to win folks over. I’m sure there’s a joke to be made here re: the double meaning of MVP. You get it.

If your recommendation looks a lot like the competitor feature your PM brought you to begin with…fine, sometimes that happens. Don’t be discouraged. If it’s a success, you’ll know you did your due diligence, and if it’s not, you can revisit your research rather than starting over from square one. In either case, you’ll be that much more capable of solving the next user problem for having gone through the process outlined above!

Interested in joining the Wayfair product design team? Browse our open positions here.

More to read on this topic:

http://www.uxbooth.com/articles/how-to-check-out-the-competition/

https://www.nngroup.com/articles/copying-a-famous-sites-design/

https://www.safaribooksonline.com/library/view/ux-strategy/9781449372972/ch04.html

https://www.invisionapp.com/blog/4-tips-for-getting-better-client-feedback/

https://usabilitygeek.com/how-to-do-ux-competitor-analysis/

http://www.uxbooth.com/articles/make-your-findings-effective-choosing-the-right-method-to-present-research/

http://uxpamagazine.org/the-other-half-of-your-job/

https://www.nngroup.com/articles/ux-research-cheat-sheet/

A Designer’s Guide to Competitor Research was originally published in Wayfair Experience Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve all heard stereotypes about “Creatives.” We’re maligned as prima donnas, dealing in the intangible, unquantifiable realm of aesthetics and brand equity; it’s all just a bit too abstract and touchy-feely for our more data-driven co-workers to handle. Stereotypes happen. If you’ve got ‘designer’ in your title, some folks are going to assume you’re the artsy-fartsy, “right-brained” type. I want to provide you with some tips on combating that misconception, but first some context for why this is especially relevant for Wayfair’s designers:

Wayfair recently merged our UX and UI teams into a single team of Product Designers. There are a bunch of reasons we did this but what I’m most excited about is something that, at first glance, could seem like a distinction without a difference: this newly-formed team of designers reports to a Product Director, not a Creative Director. I know how thrilling the nuances of org charts can be, but try to contain your excitement. Here’s why I think this is a big deal…

Design Council describes three ways a business might use design:

I. As a ‘service’: design is treated as an organizational function with a narrowly defined remit and designers are mainly technical experts that fulfill pre-defined tasks.

II. As a key perspective in the development process: design and designers are involved in the process of new product / service development, from beginning to end. In this case, design plays a more influential, sometimes strategic role, and it is considered at the same level as other functions (e.g. marketing, advertising).

III. As a strategic perspective: design shapes business strategy and, often, designers act as process leaders.

In my six years at Wayfair, I’ve seen how the role of design has evolved and become more firmly established in the corporate culture. While certain work streams have made use of design as a strategic perspective for some time, this latest org change, in my view, makes this possible (if not yet a reality) for our Product team.

Designers of Wayfair, we have arrived.

No pressure.

So, you’re a Product Designer. You’ve got a seat at the table, shaping the future of your site/app/etc, and it’s on you to break the “Creative” stereotype. Luckily, Design Thinking offers an amazing framework for cultivating solutions based on quantitative and qualitative data, and you know your stuff. What could go wrong?

The following are some of the ways it could go wrong, pitfalls to avoid as you’re collaborating with your data-driven, business-savvy stakeholders.

1. Saying “I feel like…” when presenting your point of view.

Don’t do this. You can read this New York Times op-ed on the subject, but the short version is: whether purposeful or not, this is often a way to preemptively shield yourself from criticism by stifling debate. When you preface your statement with “I feel like,” the implication is that these are your feelings we’re discussing, and as such should not be invalidated by another person. People respond (or rather, don’t) accordingly, and the conversation typically moves on without a thorough examination of your proposal. At the end of the day, we should all want the best ideas brought forward — no matter whose idea it is — and if your language isn’t serving to make that possible, that’s a problem.

2. Not including analysts early enough or often enough.

Maybe you’re “right-brained” and they’re “left-brained,” but chances are you’re both hopelessly addicted to caffeine. Invite the analyst on your next project to grab a cup of coffee, or throw a quick one-on-one conversation on their calendar. Your BI team looks at your company’s metrics to determine the “whats” and the “hows,” and when it comes time for you to shed some light on the “whys” with your UX skillz, you are going to want their input. Whether they’re helping you determine where in the user flow the experience might be broken, or helping you interpret the results of an A/B test, they are the yin to your yang. If nothing else, think of it this way: you don’t want your introduction to this person to be the meeting where you’ve all gathered ‘round to hear just how hard your recent feature blew it.

3. Forgetting that you, too, need to synthesize your findings.

In regard to competitive research: for the love of all that is good and decent in this world, DO NOT hold a meeting where you present myriad screenshots of competitors, one by one, while members of the group chime in with “I like that one” or “meh” as you work up to the big reveal of “your favorite.” I’ll write the longer version of this advice in a future post on competitive research (update: this post exists now), but what you should be trying to accomplish with said research is a fairly objective* assessment of the competitive landscape that aims to establish what is conventional and identify where you have an opportunity to align with said conventions or improve upon them to deliver a better user experience. Doing so should require that you’re taking some kind of tally of the frequency with which certain elements are observed across the sites/apps/etc that are included in your research. Personally, I build out crazy-looking spreadsheets like this one:

I’m not suggesting you present this, but I highly recommend that you do this. Because when your product manager asks “have you thought about ___?,” you’ll have an answer for them, rooted in these findings. Like a boss.

What you should present is the synthesis of your work. Show a succinct executive summary of your findings, any recommendations you have, and then as needed, provide any relevant data you’ve collected to support those recommendations. If your recommendation is “We should do X” then it wouldn’t hurt to have a stat readily available reading “45 out of 50 sites observed do X” — or some other explanation as to how you’ve arrived at your recommendation that doesn’t require magical thinking. Also, keep those screenshots ready for any visual learners who prefer an illustrative example.

4. Hiding behind those “objective” findings…

While you should strive for objectivity — as your goal should be to advocate for improvements on behalf of your users (not what you think would be, like, a really cool thing to do) — the reality is, it’s all subjective. There’s a reason I have an asterisk on “objective” in the last section: you can try to objectively look at two dozen sites in your competitive research, but some amount of subjectivity was at play when you whittled the entirety of the Internet down to two dozen sites. There’s an inverse to the “I feel like…” shield, so be sure not to fall victim to it: presenting your findings as beyond reproach (because they’re cold, hard facts, right? Get over yourself) and closing yourself off from alternative points of view. So be aware, as you’re breaking your “I feel like…” habit and generating your badass competitive research, that there is such a thing as overcompensating. Of course, it’s totally appropriate to push back and say, “based on what I observed in conducting this research, I think ___.” The worst that can happen is someone questions your methodology, and maybe as a result you find there’s a flaw in there somewhere. And from that moment forward, you’ll be a better designer for having discovered that. YAY!

5. “Washing your hands of it”

There’s no such thing. If you want to be a strategic partner in product development, you need to stay committed. Fully understanding the business goal will likely require asking your Product and BI partners a lot of questions — don’t be afraid of doing this. If you don’t think there’s an actual user problem being solved, you should feel an obligation to speak up. Actively participate in the vetting of any hypothesis put forward. Your product manager is not a client, so the whole “it’s what the client wanted” mentality doesn’t fly. Your responsibility (everyone’s responsibility) is to the user, and sometimes you’ll need to remind yourself of that. What can be even more challenging — but vital to your role as a product designer — is reminding others of that.

Conclusion

The aim with this post is to provide some practical tips for Creatives, not some pompous effort to identify “the truth” behind these left-brain/right-brain stereotypes. But to wrap up…

…The truth behind these left-brain/right-brain stereotypes is, obviously, that most of us lie somewhere between the caricatures that exist for both groups, and where we fall on that spectrum is subject to change over the course of our lives. But what’s also true is that there are totally practical reasons to have people in your company that inhabit either extreme…just not as product designers. If you’re Wayfair, you need some esoteric, trend-spotting Creatives with a finger on the pulse of interior design, so you can deliver something unique and aspirational alongside established, tried-and-true home styles. You do this for the customer who doesn’t quite know their style, but will know it when they see it, and trusts you to show it to them. But you also need the data wonks capable of understanding the inputs, outputs and velocities involved in product fulfillment with an astounding degree of certainty, such that a customer can shop from an enormous selection of sofas, have one shipped for free and on their doorstep…two days from now.

It takes all kinds of personalities to build a great product, and hopefully employing some of the tips above will help you navigate this new territory. Preconceived notions of what it means to be a “Creative” may result in some initial skepticism, but the perspective you provide is too valuable to let those stereotypes get you down, and your success will change minds.

PS: Wayfair is hosting a “drunk user testing”-inspired event on July 20th, in partnership with Drizly, Creative Mornings, General Assembly, and Boston Tech Freelancers. Tickets are $5 per person, which includes admission, small bites, and exclusive access to emerging features. Oh, and also: FREE beer and wine provided by Drizly!

How Product Designers Can Break The “Creative” Stereotype was originally published in Wayfair Experience Design on Medium, where people are continuing the conversation by highlighting and responding to this story.