(Part 3 of a 3 part series on Worker Mobility)
Part 2 of this series looked at obstacles to working outside the corporate office. The final post suggests way to evaluate and overcome obstacles to achieving a productive Worker Mobility environment.
So, how do we go about analyzing something as subjective as “user experience?” As silly as it sounds, it all starts with the user. IT people are not reliable sources when it comes to defining user experience. We have a tendency to characterize everything in terms of quantifiable metrics; a highly valuable skill at the detail level of a problem, but a barrier to achieving a holistic view. IT people shouldn’t use their own experiences as the benchmark for user experience. We know how to fix technical problems, we expect to be on-call 7x24, and we have no fear of technology.
Identifying user behaviors, as it relates to the work they perform, allows the creation of “User Experience Profiles” and the ability to group users with similar needs and behaviors. Now, you have a common language to describe types of users. The profiles describe business outcomes and not technologies. A decade ago, we used terms like “Road Warriors” and “Weekend Warriors” to describe remote computing users. This worked well when we only tried to describe connectivity speeds. Worker Mobility looks at the same problem by examining business processes, the roles people play in those processes, and how they can perform those roles from any location and any time of day.
With the User Experience Profiles we can start attaching technology and environmental requirements and looking for common characteristics across all profiles. This forms the basis for a “Worker Mobility Framework.” The Worker Mobility Framework becomes the building blocks for providing services and solving user problems. Instead of point solutions or infrastructure enhancements, we evaluate everything against the Framework and ask ourselves whether and how it can improve our overall Worker Mobility offerings. Everything added to the Framework must have metrics and a process for evaluating the performance and reliability of each component, and therefore the Framework.
The Worker Mobility Framework should include a set of core components that have typically been an afterthought for past mobility solutions. Security, data redundancy, and support (to name a few) need to be “baked-in” to every Framework component. Performance and usability must be measured using these core parts of the Framework.
We now have a clear understanding of user needs and have implemented a Worker Mobility Framework. If done correctly, we should be able to apply the framework to all of our day-to-day computing needs, be they in the corporate office, or on the road, and provide users with a robust, scalable, and common user experience performing equally well under all conditions.
Sounds easy? It isn’t. You should expect this will be incremental and iterative, and will take years to correctly implement. Vendors will tell you they can solve all your mobility problems but no one vendor has all the parts of a solution. The true solution lies within your organization and your ability to understand the present and future needs of your workforce.
The author of this article is a principal of Harvard Partners and contributor to the Harvard Partners Worker Mobility Program offering.