You should stop thinking about experience and start thinking about the conversation with the team and others

So, which conversation do you think I’m referring to?”  Really think about it for a minute. Now keep that thought in your mind.

You’ve most likely been on a project team and have an understanding of what it takes to move an idea from concept to design and then to developed and finally delivered. If you don’t know, well … It takes a lot of really smart people acting in unison. They all have to come to some sort of agreement on a lot of very complex conversations and decisions.

The group must create a beautiful, easy to use application all while making sure the product is converting customers, sales leads or performing it’s intended business function, etc. This is no easy task.

That is why most of us also know that many projects go over budget and past their intended deadlines.

I don’t have to convince anyone that these complicated and intricate business processes take a lot of conversation with a lot of people, all needing different assets, outcomes and pushing different agendas to meet their own personal or corporate goals.

The people I’m talking about are the business stakeholders, designers, developers, QA testers, project managers, and countless other business subject matter experts, directors, bankers, pilots, etc., that you’ll need to work with to make the product a reality.

At the end of the day, each of these roles has to come to some sort of consensus on what the experience should be and deliver that product in time and on budget.

Like I said before, this stuff is not easy.

Every conversation prior to that product being developed and delivered, from the time the idea comes out of the initial person’s mouth until the time the first pixels are tested for their utility, is a massively large game of telephone.

You know what I’m talking about. Yes, that’s it. The game we all played in grade school.

There are a host of conversations taking place and some of the conversations and decisions will ultimately play a role in shaping the customer’s and end user’s experience.

And an extra cheers to you if you’ve noticed I’ve not talked about the end user’s input in this already complicated conversation!

The end user will ultimately be the judge of the project success. These are the people who will be using the product. It is their input that is vital to success.

So, what do we know? We know we’ve had a lot of conversation amongst the project team and there are a lot of supporting materials to supplement the conversation. The project has gone in several directions, some good and some not so good, but you’re going to deliver a product almost on time and almost budget!

Yay! Cheers everyone!

Hold on. Don’t get too excited. On the delivery of the product, there are 2 main things to consider. Is it functioning properly and can people actually use it and complete the tasks in a timely manner with little confusion?

BOOM! Right there, did you see it?

That’s the conversation I’m talking about!

The project team bottled up their conversation and displayed it on a screen for the end user to find and interact with and hopefully complete it’s intended function.

Like I said… NOT EASY.

The application, user flows, and screens are the culmination of all of the conversations wrapped up into a pretty UI.

Think of it as sign-language. The end user doesn’t hear the conversation. He or she interprets the meaning from body movements and placements of hands, motion of arms, position of fingers, etc.

What we don’t always think about is that to the end user, there isn’t a conversation behind the scenes and if they even think about that for a minute they probably have no idea what takes place to make this UI work for them.

This reminds me of something my cousin said to me the other day. He said, “when you say develop to me or other words like the project or business analyst, you could just as easily use words like stuff. I’d still have no idea what you are talking about.”

Ha, right. Well, not really. My point is that the end users have no idea what it takes, nor should they.

The users see the conversation, unknowingly, of the project team through the lens of the UI and understand (hopefully) the interactions between UI components, screens, applications.

The conversation doesn’t end with the delivery of the product. The conversation is only halfway there and should not be considered complete until a user can sit down without any understanding of what got the product this far and be able to use the interface with minimal intervention.

This is the feedback loop and final communication that is needed to keep the project going and should be added in at certain times during the project. More to come on usability testing your products later!

Thanks for reading!



Developing Mobile Web Apps: When, Why, and How

Original Post by Thomas Agrimbau on

There are 6.8 billion people on the planet, 5.1 billion of whom own a cell phone (source). And today, an ever-growing percentage of these devices are smartphones. According to a recent Pew Research Center Study, the number of users accessing the Internet on their smartphones has more than doubled in the past 5 years, as has the number of users downloading and using mobile apps. Of those who use the Internet or email on their phones, more than a third go online primarily through their handheld devices.

Indeed, mobile computing is becoming increasingly ubiquitous… and it’s awesome.

Except, of course, when it’s not.

As a mobile device user, few things are as frustrating and difficult to fat-finger-navigate as a poorly designed mobile web or native app.

And as a mobile app developer, few things can be as intensely irritating as striving to support as wide a range of mobile clients as possible, each of which has its own frustrating set of idiosyncrasies. Whether you choose to develop a mobile web, native, or hybrid app, the quest to support multiple mobile browsers, more exotic devices, and platforms can be quite a gut-wrenching experience indeed.

As a mobile device user, few things are as frustrating and difficult to fat-finger-navigate as a poorly designed mobile web or native app. And as a mobile app developer, few things can be as intensely irritating as striving to support as wide a range of mobile clients as possible, each of which has its own frustrating set of idiosyncrasies.

Of course, not every developer today needs to worry about supporting mobile clients. But the increasingly omnipresent nature of mobile devices and applications strongly suggests that those who don’t need to support mobile clients today will more than likely need to do so in the not-too-distant future. So if you’re not already thinking about mobile app development, you probably should be.

Mobile app: Web vs. native vs. hybrid (help me choose!)

As is true with most technology selections, there’s no one-size-fits-all answer when it comes to the type of mobile app to develop. There are numerous web app best practices to consider, not all of which are technical. Who is your target audience? Are they more likely to prefer a mobile web or a native app? What development resources do you have and which mobile technologies are they most familiar with? What is the licensing and sales model that you’re envisioning for your product?

Generally speaking (although there are always exceptions), the mobile web route is faster and cheaper than the native app route, especially when the objective is to support a wide range of devices. Conversely, there may be capabilities native to the mobile device (such as the movement sensor and so on) that are essential to your app, but which are only accessible via a native app (which would, therefore, make the mobile web app choice a non-starter for you).

And beyond the web vs. native question, a hybrid app may be the right answer for you, depending on your requirements and resource constraints. Hybrid apps, like native apps, run on the device itself (as opposed to inside a browser), but are written with web technologies (HTML5, CSS, and JavaScript). More specifically, hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in mobile web applications, such as the accelerometer, camera, and local storage.

But whatever choice you make – whether it be mobile web, native or hybrid app – be careful to adequately research and confirm your assumptions. As an example for the purposes of this mobile web app development tutorial, you may have decided to develop a native app for e-commerce to sell your products, but according to Hubspot, 73% of smartphone users say they use the mobile web more than native apps to do their shopping… so you may have bet on the wrong horse.

But whatever choice you make – whether it be mobile web, native or hybrid app – be careful to adequately research and confirm your assumptions.

And then, of course, there are the practical considerations of time and budget. As one of my favorite sayings goes, “faster, better, cheaper… pick any two”. While time-to-market and cost constraints are of paramount importance in web application development, it’s crucial not to compromise too heavily on quality in the process. It’s quite difficult to recover the confidence of a user who has had a bad first experience.

Indeed, mobile web, native, and hybrid apps are all radically different beasts, each with their own unique set of benefits and challenges. This development tutorial specifically focuses on methodologies and tools to employ, and pitfalls to avoid, in the development of highly functional, intuitive, and easy-to-use mobile web applications.

Plan ahead (“if you don’t know where you’re going, you just might end up there…”)

Identifying your (or your customer’s) requirements is one of the most essential best practices in app development, mobile or otherwise. Carefully research the targeted capabilities to determine if they are achievable in a web app. It’s quite frustrating, and highly unproductive, to realize that one or more of your essential client functions aren’t supported when you’ve already invested the time and resources to design the web-based interface and supporting infrastructure.

Another common gotcha for mobile web app developer newbies is to ass-u-me that web-based code for a desktop browser will work “as is” in a mobile browser. Not. There most definitely are differences and, if you’re not aware of them, they can definitely bite you. The HTML5 <video> tag’s autoplay functionality, for example, doesn’t work on mobile browsers. Similarly, the CSS “transition" and “opacity" properties are not supported (or at least are not consistently supported) in most mobile browsers nowadays. You will also have problems with some web API methods on a mobile platform, such as the SoundCloud music streaming API that requires Adobe Flash which is not supported on most mobile devices.

A common gotcha for mobile web app developer newbies is to ass-u-me that web-based code for a desktop browser will work “as is” in a mobile browser.

A particularly complicating factor in mobile web application development is that the lifespan of mobile devices tends to be much shorter than that of desktop displays (the average lifespan of a cell phone in the U.S. is around 21 months). These shorter device life spans, accompanied by constant releases of new mobile devices and technologies, yield an ever-changing landscape of to-be-targeted devices. While working in a browser does somewhat alleviate this issue by shielding you from a number of device-specific issues, you will still need to design a browser-based view that supports many different screen resolutions (as well as adjusting appropriately for landscape and portrait orientations).

Thought needs to be given as well to supporting Apple’s Retina Displays (liquid crystal displays that have a pixel density high enough that the human eye is unable to discern individual pixels at a typical viewing distance). Several Apple products – including the iPhone, iPod Touch, iPad, MacBook Pro, iPad Mini, and iPad Air – offer Retina displays. For a mobile web app, in particular, it’s important to be aware that a Retina display makes low-resolution images (which are typically served to mobile devices) look fuzzy and pixelation can occur. The best app development solution in these cases is to have the server recognize that the request is coming from a Retina device and to then provide an alternate higher resolution image to the client.

If you want to use some of the cool HTML5 stuff, remember to verify in advance that the functionality you’re looking for is supported across the device landscape that your customers are likely to be using. For example, in iOS 6 and above, there is no support for the navigator “getUserMedia" functionality since the camera is only accessible through native apps. Two great resources for checking what’s supported on specific devices and browsers are and

Remember to verify in advance that the functionality you’re looking for is supported across the device landscape that your customers are likely to be using.

CSS3 media queries can also help you provide customized content for each device. Here’s some example code for capturing different device characteristics, such as pixel density, screen resolution, and orientation:

/* For lower than 700px resolutions */
@media (max-width: 700px) { ... }
/* Same as last but with the device orientation on land scape */
@media (max-width: 700px) and (orientation: landscape) { ... }
/* Including width and orientation you can add a media type clause,
   in this case 'tv' */
@media tv and (min-width: 700px) and (orientation: landscape) { ... }
/* for low resolution display with background-image */
.image {
    background-image: url(/path/to/my/image.png);
    background-size: 200px 300px;
    height: 300px;
    width: 200px;
/* for high resolution (Retina) display with background-image */
@media only screen and (min--moz-device-pixel-ratio: 2),
only screen and (-o-min-device-pixel-ratio: 2/1),
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min-device-pixel-ratio: 2) {
        background-size: 200px 400px;
    /* rest of your styles... */

Performance, performance, performance

“OMG, this thing is so slow!” As a mobile web app developer, those are probably the very last words you ever want to hear from one of your users. You must, therefore, think carefully about how to reduce and optimize each byte and server transfer to reduce the user’s wait time. It’s unrealistic to expect that transfers will always be done over a WiFi network, and you should know that 60% of mobile web users say they expect a site to load on their mobile phone in 3 seconds or less (source). Similarly, Google found that, for every extra 5 seconds of load time, traffic dropped by 20% (and it is also worth noting that search engines look at load times as part of their calculation of page quality score).

60% of mobile web users say they expect a site to load on their mobile phone in 3 seconds or less.

As a part of this web app development tutorial, here are a few tips that can help optimize the performance of your mobile web app and minimize latency:

  • Image Optimization. Image load time is well-known to be one of the biggest performance issues affecting page load on mobile devices. Use of online image optimizers, such as, can be helpful in addressing this issue.
  • Code compression. Compressing your JavaScript and CSS files, depending on the amount of code you have, can potentially have a significant impact on performance.
  • Database queries.
    • Some mobile device browsers don’t accept as many cookies as desktop browsers do, which can result in the need to execute even more queries than usual. Server-side caching is therefore especially crucial when supporting mobile web app clients.
    • Remember to employ the appropriate filters to preclude SQL query injection that could otherwise compromise the security of your site and server.
  • Content delivery networks (CDN). If you are planning to provide lots of videos, images, audio files, or other types of media, use of a CDN is highly recommended. Some of the more common commercial CDNs include Amazon S3, Microsoft Windows Azure, and MaxCDN. The advantages of using a CDN are numerous and include:
    • Improved download performance. Leveraging a CDN’s resources enables you to distribute the load, save bandwidth, and boost performance. The better CDNs offer higher availability, lower network latency, and lower packet loss. Moreover, many CDNs provide a globally distributed selection of data centers, enabling downloads to occur from a server closer to the user’s location (resulting in fewer network hops and faster downloads).
    • More concurrent downloads. Browsers typically limit the number of concurrent connections to a single domain, after which additional downloads are blocked until one of the previous downloads has completed. You can often see this limit in action when downloading many large files from the same site. Each additional CDN (on a different domain) allows for additional concurrent downloads.
    • Enhanced analytics. Many commercial CDNs provide usage reports that can supplement your own website analytics and which may offer a better quantification of video views and downloads. GTmetrix, for example, has an excellent website reporting tool for monitoring and optimizing the sources loaded on your site.

Your mobile web app development toolbox

“The right tools for the right job” is an age-old adage that applies as much to software development as it does to any other domain. This tutorial provides and introduction to some of the more popular and widely-used tools for mobile web app development, but bear in mind that there may very well be other tools that are the “right” ones for developing your mobile web app, depending on your requirements and available resources.


The most important trait of a UX designer

I’ve been a UX designer for about 7 years. I originally thought it was only the UX designer responsible for defining the experience as well as coming up with all of the ideas. It was about 2 years ago when I realized that these two things were important in the process, but not the most important trait a UX designer should possess.

If you are the smart creative on your project team it’s important to help define and supplement the team’s ideas, but not direct them entirely. Allow the conversation to take place with limited interruptions. Allow the team to discuss, argue, and kick around ideas on their own while making sure they stick to the topic at hand.

So, then, what is the UX designer doing? You should be listening! Actively listen to the conversation. Listen to what your team members are saying and keep a list of the best ideas. Allow the conversation to inform your design. Don’t get stuck in thinking your design must inform the conversation.

Try to keep everyone on the same page and to build a shared understanding of the conversation by providing visuals of the conversation along the way.  Ultimately, try and ensure the conversation and the design match as the team progresses through the requirements of the project.


Think of the conversation as the first draft of your design and help the team share your understanding of the conversation by providing them with visuals that illustrate how you see the conversation.





Why do you still have a website that’s not responsive

So, you or your company still doesn’t have a responsive website. Why not? Not sure what I mean by responsive? To learn more about responsive websites, check out this article by Pete LePage that explains responsive websites.

If you’re worried about the cost, don’t be.  A new, responsive website shouldn’t cost more than $300/$500 and should only take a few days.

Why your business needs a responsive website

Responsive site design has been around for a while now and isn’t exactly new. They’re now the norm and have been for the last few years.

Second, it’s cheaper than ever to set up a responsive website. For about $500 bucks you can have a secure (https), responsive website. This would include a fully responsive site that works across desktop, laptop, and mobile screens and that is secured with 256bit encryption.

What are the costs of the site?

Below is a rough breakdown of the costs for setting up a new website.

  • Responsive Website – $150 (one time cost)
  • Hosting – $15/Mo or about $180/Yr
  • SSL Cert – included in hosting
  • Set up fee – $300 (includes setting up/installing the site on the server, transferring content from your existing site)
  • Graphic Design (not included)
  • Logo Design (not included)

Any graphic design work, logo creation, branding can be added to the cost, but is not included in the $300 to $500 estimate. Also, if you’re looking to set up an online store then contact me for storefront pricing.

What are you waiting for?

I’d love to discuss your options and set you up with a new, responsive website that will bring your existing site up to today’s web design standards.

Contact me to discuss your existing site or ask any questions you may have about the process of getting a new, responsive website.


UX Design Process

User experience design is actually quite new and still being developed in the industry. Early computer interfaces were quite simple in their design. Many computer interfaces were simply structured text on the screen with a single text input.

In my opinion, the hard part isn’t following the user-centered design process. The hard part is incorporating it into the development life cycle and agile process.

The industry has come a long way since the early text-based interfaces and who knows where we’ll end up in the next decade or two?

User Centered Design

Many designers in the industry have adopted a process that focuses each phase on the end user. This is a powerful method and will ultimately help the team design a great product for the end user.

Below are the steps needed to focus the team and project on the end user and will give you that crisp, clean design the stakeholders are looking for and ultimately want to experience. These steps are not linear and decisions need to be made on when to transition from one step to another or when to transition back to an earlier step based on findings. The steps are an example of UX Design methods that will help you design a better interface.

User Research & Analysis

If you’re a UX Designer, then like me, you’re probably a creative person. The early stages of the process involve discovery & analysis of several forms of information as well as creating your own data and information via interviews, observations, and workshops.

Concept & Interaction Design

After analyzing the research materials the UX Designer and other creatives, maybe the visual designer, should start to develop a conceptual design and user flow or journey to illustrate the conversation as it is at that time.

The designer should create user journeys, storyboards, or other creative assets to best illustrate the conversation. These assets should be used to help keep the team on the same page with regard to the problem the team is trying to solve and what a possible solution may be.

Usability Testing

The UX Team and Business SMEs should try and collect feedback as early and as often as possible. Ultimately, you want to collect feedback in an unbiased way. This can prove to be quite difficult but is vital to collecting good feedback.

My advice is to allow for the users to explore and use the design without any interaction with the moderator or members of the team. Allow them to fail and to struggle for the solution. Also, make them think aloud. Don’t let them silently navigate your design. Make them talk, by asking questions or simply by reminding them to speak aloud as they use the prototype.

Visual Design

I’m not a graphic designer but love this stage of the process. It’s at this point in the process that the design starts to become real, in my opinion. Once the visual is applied the end user can really get a sense of the design.


Now the design is real! Working with the UX Developers apply interaction and transitions in a way that finishes the story of the page’s final design. Consider how you want to information to relay the story to the end user. Make the final design speak to the user

Touch of Modern Website

I’ve been a member of Touch of Modern for a few years and have grown to love their product line and deals. The site is nicely designed, but there are a couple things that annoy me when on their product page.

They have a nice big product image and usually a lot of thumbnails. They also have nice, large font and a very nice call to action.

However, if you hover over the main image to see it zoomed in the design covers the product name, price, and call to action. The description is also blocked.

The large image is about the same size as the zoomed image. I’d suggest showing the zoomed image in the same place as the large default image to allow for the user to continue reading all the information even while zooming.

Another issue is the interaction between the main image and thumbnails. When the large image is in view you are unable to see all of the thumbnails.

And if you scroll down to see the thumbnails and select one of the lower thumbnails, you’ll have to scroll back up to see the image change. This forces you to do a lot of extra scrolling. It’s not super critical, but on a scale of 1 to 10, it is probably a 6 for annoying.

I’m not sure what a good solve would be, but something can probably be done to keep the user from scrolling.

If you have thoughts on how this could be fixed, drop a comment below.