Suppose your organization has several software applications in its product line. You’ve learned from your users—or maybe your competition—that your applications must be available on mobile devices…NOW. And they need to be responsive to the screen size and resolution of the device they’re being used on.

Easy, right? It’s just another level of software complexity. Or maybe it feels like more trouble than it’s worth. If you could just hold out for another couple of years or so, somebody will automate the process and you can use some magic-wand software tool that’ll do it for you.

But this time, that’s not going to work. For two reasons:

First, converting to mobile and/or responsive involves RETHINKING, not just SHRINKING. What people do on their phones and tablets while they’re on the go is different than what they do sitting in their offices. You need to make all your apps behave differently, not just fit on a tiny screen. It’s like you can’t just shrink an elephant to the size of an ant; you need to make fundamental changes, not just scale changes.

Second, the pace of development is too fast to wait for tools to catch up. You’ll lose your user base while you stall for time. Changes in hardware, OSs, screen resolutions and more are too fast for do-it-all UI tools to appear for the foreseeable future.

Based on completing over 100 of these projects, we’ve seen pretty much all the mistakes companies make in converting application suites to work on any device users want. We’ve developed workarounds for those mistakes. Here they are, summarized:
1No Room at the Top. A CEO can’t just mandate the effort, have it posted to the internal website and move on to her next project. You must have an executive champion support the effort. Regular update meetings, unannounced check-ins, cheerleading and so on, are critical. The reason is that the involvement and support of your entire organization is so essential to success that if you don’t have someone senior focusing the effort and breaking logjams, the team gets pushback from everyone.
2Style Guide Lip Service. Paper style Guides with detailed specifications just do not work. The teams chafe at using them and typically honor them in the breach. Each app seems to “need” a few exceptions, which, taken in the aggregate, mean no consistency. To get consistency, provide teams with reusable code. It’s amazing how this enforces consistency and saves time.
3Reinventing the UI Wheel. Dev teams always default to doing UX design from scratch. Even if they use a library of UI controls, it’s not very helpful when used alone. The fix is to focus on the most useful anatomical unit of UI, the Reusable UI Panel. It has specific functionality, not just an element like a text box. Survey all your apps; find the reusable UI panels that are common to all of them.
4Doing It All at Once. If you’re far enough behind, you’re tempted to get all your teams going at once. What a great story for investors: “We’ll be mobile and responsive by (fill in the month or quarter)!” Don’t try it. Instead, get the first app done. It becomes the model, provides the reusable UI code for other teams and is the single best way to reduce risk.
5Chiseling Your Bible in Stone. Companies want a permanent solution, a UI design system that lasts. It’s not like that. Your UX design system is a living standard. Plan on updating it every 6-12 months, then do it. If users know the UX will be updated, they suggest ideas. Otherwise, they treat your app—and your company—as stagnant.
6Prioritizing the Big One. Companies usually want their biggest app to go mobile first. So, faced with not being able to convert them all simultaneously, they wait for a release schedule that includes mobile. Don’t. It takes too long. Just get going with the app, big or small user base, with a release date coming up. Then do the others product by product, development team by development team, in the normal course of your work. Be opportunistic.
7No External Input. We see the companies that haven’t gone mobile and responsive yet are often the ones without much user input. If that’s you, now is a great time to effect a change in your organization’s permeability to user input. Create Stakeholder and User Advisory Groups. They are valuable for execution and facilitating adoption.
8The No-Plan Plan. People get so focused on having their apps running everywhere that they think only about the destination but not the journey. You need to plan around five elements to get where you want to go:
  1. Unified UX Design System. This is the “secret ingredient” of successful mobile projects. The Unified UX Design System identifies the responsive reusable UI panels that go into all your applications. And it describes how they fit together.
  2. A Library. This is reusable UI code based on your chosen technology. It’s what enforces the UX Design System.
  3. Methodology. It has to be reasonable for your product and development teams to handle.
  4. Governance Policy. Teams need to know who to ask for guidance on resolving conflicts.
  5. Rollout and Training Approach. Employees and users need to know about the what and when of the new releases, how to use them and how to get support.
More HELP for Moving Your Suite to Responsive and Mobile—No Charge.

These mistakes and their fixes may seem obvious. But don’t be deceived into thinking that they’re easy to avoid. You’ll have to spend time and energy on them. You may benefit from more than just an alert about the mistakes that may be in store and their potential solutions.

If you’d like to find out what it’s like to have an experienced guide, it couldn’t be easier. Or cheaper. Click below and we’ll set up a time for a conference call with our senior leaders. We’ll give you a road map to get there, show you examples and more in less than an hour. It may be all you need for a successful transition.

Help me unify my UX