UX/UI design for websites relates to how a site ‘looks and feels’.  User Experience (UX) and User Interface (UI) can be thought of as the art applied to the science behind any good website.

UI refers to the look of the website:  This can include the high-level, visual design of the site, including areas such as use of background colors, images and graphical elements; to incorporating a brand’s logo and color scheme.  And UI can also refer to the more detailed design elements for user-actions, such as buttons, icons, sliders and data entry fields from which a site visitor can interface with at the point of a cursor, using their keyboard and mouse, or through finger touch and voice commands.

UX is a little harder to define than UI.   UX relates more to the way it feels to interact and engage with your website.  Some examples are:

• Do web pages on the site load quickly, or annoyingly slow?
  
  
• Does the site user find efficiently, and intuitively, the most accessed features or content on your site, or do they feel like they are scrolling endlessly to access areas with key content or functionality?  
  
  
• Does the user land on a page with an endless sea of copy about subject matter or content type, or is the user allowed to absorb information in more scannable, stepped pages (often referred to as ‘content chunking’)?
  
  
• Are the site’s web pages easy to navigate into and out of, or does the site visitor lack a simple ‘bread crumb’ trail to navigate seamlessly between pages, and commonly accessed areas of interest?

When a website’s UX is done well, the user doesn’t recognize it at all.  In other words, the UX designer has figured out exactly who the site caters to (the ‘user persona’), and has anticipated what most appeals to that user, and what steps the user is most likely to take in order to obtain what they need. 

The website you are creating may have the greatest content, features and functionality that your desired user could ever want.  But if your designer ignores good UX/UI principles, there’s a good chance the site visitor will not appreciate, and engage, with all that functionality you’ve created.  Which is to say, they might quickly leave your website, and never come back!      

If you would like a free consult to discuss design considerations, or any other ideas for your website or mobile app project, we’d love to hear from you! 

It’s important to first mention that a successful developer usually views a new client as a long term partner, not a ‘one-and-done’ project.  If you are working with a developer that views working with you as a partnership, then you can be sure that the more time and effort spent in the discovery and estimation process, the more focused and lean your final cost, and final product!

An experienced developer knows that almost every client can save a ton of money by narrowing down the key features required to launch version 1.0 of the software.  This not only saves in development costs, but it allows the product owner to focus on successfully demonstrating core features to users, while facilitating the users’ feedback to determine the best enhancements to spend money on in version 2.0 of the software.  Additionally, experienced developers know that if you don’t save a healthy amount of your budget to obtain and support users to your platform after the initial launch, then your software is likely to fail.  This obviously doesn’t work well for a long term developer/client partnership!

To arrive at an estimate which you can rely on, it’s helpful to view the process within three main areas:

• Define the software users’ needs.
• Define the process to complete the project.
• Define the metrics by which the project will be judged a success.

In this blogpost, we will focus on the first area — Define the user needs

What problem do you solve?

When discussing the concept of your project with your developer, including all the features and functionality of the software, make sure you start by defining the problem you are solving for a user.  E.g., the way it’s currently done looks like X.  With our new digital platform, the process will look more like Y. In that process, be prepared to literally explain every step you envision a user taking from the moment they’ve logged into your software, to the time they have completed a session and logged out.  Don’t worry if you might be missing something, as there will undoubtedly be plenty of refinements to the user experience as you iterate with the developer’s creative team about your concept.

A day in the life of your user(s)

In order to ensure that you are covering all the needs of your user base, you may want to start by creating what developers call ‘personas’.  A persona defines an archetypical user of a particular software system.  It’s a detailed example of a fictitious person who would use your software.  It’s usually a two to three paragraph write up describing one of your user types, where there may be a handful of different user types (and thus a handful of different personas which you need to define).

When you write a persona, you start by creating their name, then their socio-economic and family background, their daily routine, their primary needs and desires… all within the context of how your software might touch one small aspect of that routine, and improve their experience.  You may refer to these personas by name throughout the entire project so that you better guide your developer’s decisions about functionality and design.

With personas, now the entire design and development team can be on the same page with you, and the product managers of your software, when discussing how each feature in your software directly affects each of your primary users.

Prioritize features and functionality

Rank all of the possible features that users of your software might have.  Start with those that the user would need most in order to solve their problem, to those that would be ‘nice-to-haves’.  Some features will make version 1.0, while others may fall into later versions of the software.  A good developer usually has no problem telling you the features that you DON’T need in version 1.0.  Yes, that’s less money in their pocket initially, but again, it all comes down to making sure you have remaining capital to market and support your software after launch.  This translates to a successful product and long-term partnership with your developer.

Roadmap it

Don’t be embarrassed to explain your features by demonstrating them with crude, even ‘back of the napkin’-type sketches.  Your developer’s UX/UI designer will be thankful for every bread crumb that you can give them so they may design something that successfully translates your vision to the screen.  Your developer may even convert your sketches into an abbreviated set of storyboards and wireframes before even calculating your initial project cost estimate.  This will help to eliminate any misunderstandings about what you can expect in your final product.  Of course, if you decide to pull the trigger on your project after the discovery scope and final estimate, then the developer will start by completing a highly detailed set of wireframes that will inform the final designs, and the code behind them.

Utilize competition

During your discovery scope, be sure and mention any other websites or mobile apps that provide some of the same features you want to provide to your users.  This can really help your developer hone in on what’s currently available that works, and what doesn’t work, for solving the same or a similar problem that your software seeks to improve.  Most developers take these live examples and use them to refine their search for even more examples of user experiences, or to create new user experiences to further improve your software.

Summary

Defining user needs can be the most time-consuming portion of your project.  However, thoroughly tackling this stage will help create a finished product that becomes something your users feel like they can’t live without!  And before you ever spend a dime to code your software, you’ve narrowed it down to only those features that your users need, which of course can save you a lot of money in development costs!

In the next blogpost, I’ll discuss how your development team can take your completed user requirements and convert them into a detailed estimate and timeline that you can understand, and rely on!

Lack of Native iPhone/iPad Functionality

Apple knows that one of the main things that sets apart a mobile optimized website (i.e., a website that is easy to navigate on a mobile device) and a mobile app, is the ability for a mobile app to provide a more robust and engaging experience to the user through integration of Apple’s native device features such as the camera, the microphone, GPS, swipe navigation, etc.

Think back to the first time someone showed you that really cool mobile app they were using.  It was almost like magic to see things such as GPS mapping overlays and limitless feature sets built around photo, music and contacts integration.  This list of native features now is mind-blowing, with things like augmented reality views of items inside the mobile app with the surrounding landscape outside the mobile app.  Accordingly, it’s not a surprise that Apple wants to make sure that you are highlighting at least a few of their native features if you are going to build on their platform. This is probably the single biggest deficiency we see with app ideas that come to us for initial development.  Too many static content tabs, and not enough magic!

The Website as a Mobile App

Too often we have clients come to us to build an app wherein the majority of their app is just going to be links to their existing website.  If Apple wanted to get in the business of hosting websites they would have done that a long time ago.  Remember that it always comes back to this core principle with Apple of providing users a highly engaging user experience.  If you are in an app and click on a button or tab, and the app stops, thinks for a second, then spits you completely out of the app to a slow loading website… ask yourself if that is an engaging experience that you’d expect from a mobile app.

While certain, rarely used, content tabs in an app are fine being links to Web landing pages, the vast majority of key features and functionality in your mobile app should be native within your app.  We understand why certain businesses want to have one more distinct, digital media highway (besides the Internet and Facebook) for people to find their company, but so does Apple, and it’s why they reject apps which are essentially just websites trying to onramp the App store freeway.

Abnormally Long Load Times

Somewhat overlapping with the problem of ‘website as a mobile app’, as discussed above, is the problem with apps that take abnormally long to either open and/or for a particular piece of functionality to occur.  An example of this might be when a user submits or enters something in the app in order to obtain information back, or make something appear, from that action.  If there’s a progress bar that barely moves or takes forever, Apple will question the Web server set-up you are employing, and subsequently reject the app until you pony up for a better server package and configuration to host your data calls.  This is where a good app developer can really be an asset to you for configuring the best server set-up on a host provider that will ensure that your app runs efficiently, but also doesn’t break your bank in server costs.

Apple’s standard is that any app that takes more than 15 seconds to load from scratch is a candidate for rejection because users are not expected to wait longer than that duration.  Much of the solution to the problem also involves designing the app user experience (UX) so that a clear user objective is performed by each user action, combined with the code being written correctly to expedite the calculation time.  This is often a major difference between an inexperienced developer and one that has experience solving problems using the latest coding conventions and programming logic.

Over the years, we’ve submitted hundreds of apps to the App Store.  In that time, we’ve learned that there’s a lot of grey area to navigate within the stated App Store guidelines, which often seem a bit overarching.  And while it is certainly helpful to know what the most common app rejections are according to Apple’s developer site, we find that there are actually just a few areas which we see entrepreneurs and businesses overlook, time and again.  Each of them is common sense if you just put yourself in Apple’s shoes, and what clearly differentiates using their mobile app ecosystem from just viewing internet over a smartphone.

Completely differentiate your app from your website.  Otherwise, you could spend a ton on development hours creating something that Apple will simply reject at the end of the day.