Designing for Devices

Creating a design that works well on desktops, tablets, and mobile devices is often seen as a daunting and intimidating exercise. Clients worry that there will be an overwhelming number of decisions to make, and they often become confused or sidetracked by pre-conceived notions about what “responsive” and “adaptive” design means.

At Akendi, we’ve figured out a simple approach that works well for our clients: we design for the user’s device.

Instead of discussing the differences between (or the merits of) an adaptive versus a responsive design, we focus on “designing for device.” This means that we work to determine the specific device(s) the end user will use, and design the product accordingly through strategy, research, design, and then coding. This means uncovering user requirements then creating a design that meets those requirements and only after that has been resolved, building it in a way that is appropriate.

We understand that discussing pros and cons may be important further down the road. But we also know that nothing is black and white. Ultimately when designing for device, we end up with an end solution that acts as a hybrid, utilizing the best points of responsive and adaptive based on user needs and the business requirements that support them.

Our approach has two main advantages:

• It’s simpler: By simplifying technical discussions that delve into backend issues and topics like breakpoints and resolution sizes, we give clients a clear picture of the process and ensure that everyone is onboard with the design direction.
• It’s more effective: If we were to define the coding method before understanding the user needs, we’d be putting the cart before the horse. Ultimately, what our clients really want is for their interface and content to be optimized for the device that their audience happens to be using. Whether the site is served up server side or device side doesn’t matter to the user. They just want to purchase their item, see their movie time, or do their research.

How We Do It

Our approach puts people, not technology first. We start by talking to users and stakeholders to understand what the end user will be doing with the product, website, or app. Understanding which tasks will be performed on which devices is key. We prioritize their key tasks by device, and develop wireframes to test our assumptions. Only once those wireframes are tested with actual users do we actually begin to create the visual approach to the design.

During this process, we consider three important viewpoints: the interaction design, the visual design, and the technical development.

• Interaction Design: After we’ve defined the end users, we explore how these users will interact with the site. We ask questions that include:
  • How do I optimize the user experience by device?
  • What tasks are they performing?
  • How do I make those tasks as easy as possible?
  • What kinds of content is that user looking to find on a desktop, mobile device, or tablet?
  • What functional controls do I use to create consistency and ease for development?

• Visual Design: Visual design brings the experience to life through the application of captivating, relevant, and on-brand design. We ask the following questions:
  • How do I create the best possible experience from a visual point of view?
  • How do I make sure that the user can properly touch/view all content?
  • How do I properly represent the brand and the appropriate tone?
  • What size do I actually make my layouts so the designs can be built properly?
  • What will happen to my design between breakpoints or when the user opens the browser beyond a breakpoint?

• Technical Development: This step brings everything together and creates the final product. Our questions at this stage include:
  • What framework should I use?
  • What happens at breakpoints that there aren’t layouts for?
  • How do I fill in the blanks?
  • What are the pros and cons of delivering the site server-side vs. device-side?

The Details

While the design-for-device approach avoids unnecessary discussions around responsive vs. adaptive, there are still technical decisions to be made. These include:

• Breakpoints: We must decide how many breakpoints are necessary. When a website changes to be optimized by device, that’s a breakpoint. Creating multiple breakpoints takes more time and money but there is a minimum amount of work required to make the site work on multiple devices. To work within these constraints we generally recommend three breakpoints, but more is better if there is time and budget to allow it.
• Resolution: When choosing a layout resolution, we refer to W3Schools to determine the most common resolutions that are being used by the public. We combine this data with our understanding of our particular users and their environments and make a final decision on resolution. As of Jan 2016, 84% of desktop users are using 1366px or higher. The most common resolutions that we design for are 1366px, 780px, and 340px.
• The Grid: The grid is the framework in which we position the design elements and content. The grid ensures a consistent and repeatable design so that users can understand where they are in the hierarchy of the site. 1366px is the size that we set up for our art boards in Adobe Illustrator, but that doesn’t mean that the design elements touch the edges. We have to leave sufficient margins and padding to allow room for the browser and for scrolling. For desktop, we create a 12 column grid. Tablets and mobile devices will follow the same grid in that the margins between the columns are fixed, but have 6 and 4 columns respectively.

Here is an example of a desktop grid:

And here is a tablet grid:

And finally a mobile grid:

• Templates: Websites are typically made up of templates. Templates are unique pages that are repeated to make up the whole site. The content and imagery will change from page to page or section to section, but the structure of the page is repeated to form a logical structure that is understood and followed by the person interacting with the site. We determine what the templates are by understanding the scope of the project then making a thorough evaluation of all of the wireframes created. (Remember, these cover the key tasks that need to be performed on the site). We create a document that captures the templates then maps them to the wireframe deck so there are no surprises during the design process. We then design the templates based on the creative workshop and brief and chosen concept direction.
• Collaborate with your coder. Once the design is established, it’s time to start talking to your coder about how to execute the design. Up until this point, we made have had technical requirements discussions, but haven’t resolved the final approach. This is when we start discussing the final outcome and what should be done during the coding process to ensure that the person who is using the website can use it on their chosen devices. Now that we have a design, we can determine what to do between breakpoints and how to best make the design behave so the transitions from breakpoint to breakpoint are optimized.

It’s All About the User

When you understand your users and the devices they will use, you can create an experience tailored to their specific requirements. You don’t need an interface that accommodates hundreds of variables, and, with proper testing, you won’t have to worry about any “unknowns” you might have missed.

If you’re considering a new design that can accommodate multiple devices, learn more about our Mobile UX Design services or contact us to chat about your particular project!