Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Account Creation, Standalone Mobile Websites, And Dealing With Non-UX Designers

Editor’s note: Welcome to Smashing Magazine UX Design Q&A. It works like this: you send in questions you have about UX Design, and each month we’ll pick a handful of questions asked by our readers about best practices in designing smart and usable experiences. They will be answered by Christian Holst1, a regular author here on Smashing Magazine and founder of the Baymard Institute2. Prior to cofounding the Baymard Institute in 2009, he worked as a usability engineer in the hearing-aid, credit-card and consulting industries.

Location Of Registration Form During Checkout Link

Sheri asks:

“If an [e-commerce] site offers guest checkout, where is the optimal place to put the account creation fields (that is to say, the password and password hint fields)? During checkout (early or late), or on the order confirmation screen?”

We generally recommend the latter option: making the password field optional and moving it to the order confirmation page (sometimes referred to as the “Thank you” page).

Crate & Barrel offers optional account creation on the order confirmation page
Crate & Barrel lets you create an account on its order confirmation page, removing significant friction and frustration from its checkout process. Ideally, it would also list a couple of the benefits of creating an account.

Moving account creation to the order confirmation page will remove a lot of friction during checkout because creating an account isn’t just a matter of filling out a password field. Rather, it is the beginning of a complex thought and decision-making process for the customer: “Which password should I choose?” “Do I trust this website?” “How will it store this info?” “Does it also store my card?” “Will it send me a lot of newsletters3?” “Do I want an account here?” “How often will I shop here?”

Further Reading on SmashingMag:

The performance of optional registration forms8 at different positions in the checkout flow will vary from website to website, depending on how natural it is for a customer to hold an account with a particular type of website or business. For example, having an account could be a very integrated part of a software product; in such a case, placing the (still optional) registration form as a separate step in the checkout process might make more sense. But in general, take account creation out of the checkout process, and invite it after the sale has closed (on the order confirmation page).

Standalone Mobile Websites Link

Michael Meininger asks:

“What are your thoughts on a standalone mobile website with “browser sniffer” technology in place?”

In general, the more complex a website’s features, the more likely the mobile experience should be significantly different from the desktop experience. The bigger the difference between the two, the stronger the argument for having a standalone mobile website. Of course, maintaining two coexisting versions of the same website comes with many issues, especially in terms of maintenance (of content, code and design).

Therefore, a responsive design is a better solution in some cases, but it depends very much on the size and complexity of your website, as well as on your organization’s strengths and weaknesses. It’s a nuanced issue, with many gray areas and with good arguments both for9 and against10 having a standalone mobile website.

Let’s look at a concrete example. Our user research shows that for a mobile e-commerce store, animating carousels come with a whole slew of usability issues due to the lack of the hover state; therefore, never use them for website features, events, navigation and so on (use them only for products). However, on a full e-commerce website, a carousel on the home page might be an OK solution if implemented properly. And there are many more of such mobile-specific usability guidelines.

From M-Commerce Usability Test of Toys R Us

If you can achieve this by designing for mobile first11, then a responsive design can be truly great — not just maintenance-wise, but also UX-wise. But merely making your existing full website scalable to different devices won’t be enough to offer a great mobile experience if you have a very complex website such as an e-commerce one.

And if messing with the full website’s existing structure and content isn’t an option, then you might be forced to create a standalone mobile website in order to provide a decent mobile experience — although maintaining content on the two different platforms in parallel could turn out to be both expensive and messy. So, if you have a simple blog, a portfolio or a small company website, then a responsive layout might be a better fit.

Ultimately, what’s important is that you pick the solution that enables you to create the optimal mobile experience within your unique set of constraints — your organization’s strengths and weaknesses, the website’s complexity, and the resources available to maintain the content, code and design.

Dealing With Developers Who Believe They Are UX Designers Link

DMC_ asks:

“What is a good way to deal with a development team that believes they are UXDs? #inmatesrunningtheasylum”

Giving specific advice without knowing your context is, of course, impossible; but take a moment to appreciate how great it is that your development team cares about UX. This is a good thing, because you won’t need to convince them that the user’s experience is important — you “just” need to show them how your solution will enhance it. Developers tend to respond well to rational arguments and solid logic backed by good research. Present a strong case, supported with real user data, and you should be able to persuade them.

If you don’t have any research to support your case, but are rather basing your arguments on a UX education or on years of experience, then the challenge is one of education. Teach them what you know. If they learn what you know (which requires good teaching) and they see the data you have (again, find research to support your case) and yet they still don’t find your case compelling, then your dispute is one not of training or information but of belief. If it has come this far and you’re still in disagreement, then start to question your own case.

After all, if your UX recommendation is ultimately rooted in your own belief and not a consequence of solid arguments and data, then it wouldn’t be immediately obvious that resources ought to be spent on implementing it. If you still feel strongly about your case and want to push it forward, then reframe your proposal: make it a case for experimentation. If you can’t prove the validity of your recommendation, but they can’t prove their case either, then insist on testing the two (either through A/B tests, qualitative usability tests or whatever makes the most sense for your project).

This will result in real user data showing which solution works better. If they are confident in the superiority of their proposal, then they shouldn’t be afraid to put it to a test. Obviously, you shouldn’t be afraid to test your proposal either. Whichever solution performs better in the test is the one that gets implemented.

Of course, this whole approach doesn’t just apply to development teams but can be used when dealing with managers and clients, too.

Client Requests That Compromise The UX Link

@NathanJY asks:

“What do you do when the client wants to compromise the UX with unnecessary and nice-to-have elements?”

You could try winning them over with the approach described in the previous answer. But more specifically, the very best advice I have is to include hours for performance metrics and analytics work in your contracts whenever possible. When performance analysis is a part of the assignment, then you will largely be judged on the actual impact of your solution. However, if it isn’t a part of the assignment, then the client can really only judge your deliverables in the format and context they are delivered in.

For example, if you deliver a set of designs done in Photoshop, then the client will look at them and give you feedback based on that. Adding context to your deliverables is a good idea, then, either by presenting them in a meeting or perhaps by creating a simple PDF document in which each design is annotated or described. This way, you can show your reasoning behind each design decision and support it with research and data where applicable. By articulating your decisions, you give the client a chance to see the design from your perspective and to understand your reasoning.

If feasible, run simple small-scale usability tests, recording the task success rate12 before and after the proposed changes have been made. Recording these test sessions is crucial because you can then show the client video clips of users despairing with one of the website elements that they wanted to add (or remove). This is a great way to evoke empathy in even the most stubborn clients.

In general, this could be a good way to get early buy-in from the client and convince them that they want (and need!) a simple and elegant UX. Educate them and present case studies, such as “Removing Company Name Field Saves Expedia $12 Million” and “The $300 Million Button13,” and argue that getting the details right can have a significant impact on the bottom line.

Any Questions? Link

If you have any questions that you would like me to tackle for a future usability Q&A column here on Smashing Magazine, please ask them using this form.

Credits of image on start page: opensourceway14.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14

↑ Back to top Tweet itShare on Facebook

Christian Holst is the co-founder of Baymard Institute where he writes bi-weekly articles with their research findings on web usability and e-commerce optimization. He's also the author of the E-Commerce Checkout Usability and Mobile E-Commerce Usability research reports.

  1. 1

    As for the developers thinking they are UX designers, I think the using data and research is a good solution. I also have found if you involve developers in the design process they are much more likely to be on board with the final solution. The key is to make the final solution the team’s solution, not your solution. As soon as it becomes a situation where it is your idea vs their idea you are already heading down a problematic path.

    Sorry for the self promotion, but here are some tips about how effectively to involve developers in the design process:

  2. 2

    As for devs,

    Nope, A/B won’t and shouldn’t work.

    Think of it this way: a senior developer costs 10 000 EURs a month. They usually implement some complex stuff you say in at least 1-2 weeks. That’s still a 5 000 EUR bet on something they don’t believe in.

    Mingling with papers and photoshop is one thing, and teaching a computer to do it by itself is another one.

    However, exactly that’s what you can do: create a high-fidelity prototype, go out to the fields, grab users and test that prototype.

    Do BOTH versions. The one they insist and the other one you believe. It takes you an afternoon, much less than the time you spent arguing I guess.

    Programmers are designers; they’re just designing with a different perspective sometimes. I also met UX designers who’ve never done user research before at all, doing crazy interactions no ordinary human would understand.

    I understand programmers are able to do that as well on their own, however, that’s where users come in: real software is made for real users. Real users means that they can be found on Earth. Go out and find some.

  3. 3

    Yeah, beware… here in Germany it is totally crazy. Traditional “Designers” emerge from the field of print design … still!

    Today you find among the youngsters those creatives, that did start with web first. but they are coming slowly. and mostly they are so highly engaged, they believe what ever comes to their own mind. there is no sense for substantial testing and self-critic questioning.

    Many visual designers dont have a valuable insight into functionality of browsers nor do they have a clue how and why our specs were chosen as they are.

    Reduncy in IT can be something positive or something bad. Can you explain this to regular designers easily?

    I guess: Not as long as they havent fit the cap themselves and went a mile in your shoes.

    Sorry for being reactionistic…

    Who are the better UX-Designers? Backend Programmers, Frontend Guys, Graphics Designers, Conceptionits?

    Or those who went out and collected experience and expertise in the field of UX Design, because they saw, there is now way to seperate between frontend or backend functionality and visual design matters…

    UX is complex. It is where it all comes together. So why dont we solve this problem together and raise our awareness of ourselves our work and also our awareness towards the product and its users?

    We have to start from scratch and like Aristoteles:
    The only thing I know is, I know nothing.

    (Its all assumption, in rare cases experience, in even less cases its is done by reason.)

    So the therapy would be: questionig ourselves, what we can do to become more intelligent and smart.

    Have we really been up to this task in the past?

    The reason why we have UX designers today is, we folks failed already to communicate the right way and CEOs didnt see the reasons why there is to spend much money on this field.

    Though we have to deal with the same UX problems today, and now as we can name the “problem solvers”, we are willing to hire them and pay shitloads for their special skills, as we havnt learned to built up those skills on our own yet.

  4. 4

    “Developers tend to respond well to rational arguments and solid logic backed by good research. Present a strong case, supported with real user data, and you should be able to persuade them.”

    Gee, I kinda hoped that would apply to everyone, not just developers. Does this mean designers tend to respond to irrational arguments with no logic or evidence?


↑ Back to top