I thought I’d take some time to go through the Dell Shop app I helped design, particularly since the design process helped me realize the lack of best practices surrounding touch devices. This app was created for the Windows 8 OS. (Also, here’s the article I wrote for uxmag.com on designing for Windows 8.)
This is pretty standard, but one thing you can see is that “Featured” does not have a ‘>’ carrot next to it, indicating that it is not an interactive element. As we go through the site, you’ll notice that Microsoft is really pushing for an exploratory experience, which is super burdensome on the user. And users can be lazy. There are going to be issues. Also, it begs the question of how you divide up blocks of information – and everything can be a building block for design. For instance, do you differentiate between CTAs and the image? Do you keep those elements separate so that you can manipulate them further at responsive breakpoints?
Search results landing page.
This is tricky – see the touch icons? They’re not interactive, even though it appears that they are; it’s actually one element from the development team’s perspective. The problem is that this image is used in various locations of our shopping hierarchy. In an ideal situation, could that image exist as a separate element from the price stack? Sure! It could contain a quickview mode since hover does not exists on touchscreen devices. This also means that swipe to select (the standard selection action Windows is pushing) could exist in the same element environment as a tap/touch to view. For clarity: if I wanted to select the XPS 10 product card, I could swipe it anywhere inside the card, including the image, and the action would take me to the next level down (e.g. product details page); at the same time, tapping to select the image also produces another action (i.e. opens up a modal). Having two actions in the same element area, such as the image, is definitely possible, but it means that users will have to understand what each action in a space does, and it also takes extra planning on the part of dev + design. It might also be helpful to note that Microsoft sets some parameters on what elements can have multiple actions (such as scrolling direction) that may affect app/platform design consistency.
Another issue I have been thinking about a lot lately is how a search results page would look on a huge screen. Supposedly, there are no limits, right? We could project this onto any sized monitor or even television set. I believe (and correct me if I’m wrong), that Microsoft has built in some sort of inherent responsive measures, meaning they’ve built their code according to a specific grid scale, and our search results blocks (in this case, the individual card) automatically has breakpoints according to screen size. On a very large monitor, does this make sense? What is an acceptable range of motion for eyes to trek on a screen? On a tablet, it’s easy to swipe horizontally; on a much larger surface area, I wonder if lazy loading information vertically on a dramatically reduced set-width would be easier to scan. Just some thoughts as responsive design takes over my life.
Some cool features that are perhaps not universally beloved on this page. I really enjoy multiple scrolling directions, like what we’ve got going on here with each tab section’s ability to scroll vertically, and then the whole page swiping horizontally to move through the tabs. The product stack on the left is anchored. This is a big no-no says Microsoft, as far as I understand, but e-commerce folks will understand that it’s everyone’s biggest fear that the consumer will get to a product details page and not know how to add the item to cart! (!!!! x10!!). Fear not, stakeholders of the world. I do in fact like the not-at-all subtle ‘this is the product you should buy’ product stack space since it’s a good summary of a lot of potentially confusing tech information. You probably don’t need a product stack for jeans, though, since I can’t see a jeans’ product details’ page taking up more than one screen.
Follows the same pattern as before – cart summary stack stays anchored to the left, user scrolls horizontally to see multiple items.
You can see the anchored left rail is where we do a lot of important functions and proceed forward – this is super important in the checkout process! We don’t want users to proceed without filling out all the right information and we want to save them the stress of having errors returned when there should be immediate error messaging (client-side or soft validation) for simple things like phone numbers or e-mails, as well as client side validation (which is what happens when the user hits the “Review” CTA). I’m wondering how other sites are handling error anchors for long lists (say, your tax forms)? It’s so hard to scan on tablet sized and smaller devices that I’d much rather prefer Microsoft to provide some sort of standard messaging system that is not inline but anchor-linked based (not super applicable to our Dell Shop app but just in general).