Mobile first or workflow first?

Mobile first was suggested as a means to help an organization build both for mobile devices as well as the desktop application. The attempts at taking fully featured applications and wedging them into the mobile device did not work. Trying to take something with few constraints and simplifying to something with greater constraints seldom works. In this case the addition of unique features and abilities were missed on many developing mobile applications.

So mobile first arose as a way to build out applications considering the greater constraints of the mobile applications and then expanding to the desktop. This process all works well when the intent is to give the same features in both applications. However, when do you ever want the least common denominator between 2 technologies?

How does this work in real life? Are we designing to the workflows the users do? Or are we designing to the silos we build in the organization? We make the desktop apps in the desktop team and the mobile apps with the mobile team. This means that we hire UX designers for mobile or desktop applications but we are not hiring them to solve the user’s problems.

IDEO design for Bloomberg

IDEO design idea for Bloomberg integrating desktop and mobile devices for enhancing workflows -2007

When you are at work, are you using mobile devices? Do you use them in exactly the same way as the desktop application? Do they serve different purposes depending on the tasks you are working on?

By analyzing the user’s workflows and how they do work we can do a better job designing for them. Incorporating the tools they use in the context of the work and environment will drive differing designs for each device. The strengths of the device in the context of their work can be enhanced. For example, at the desktop, many users have large monitors or multiples. The real-estate available allows for a greater display of information in context of what they are trying to do. Using both monitors to do, track and monitor work is helpful and increases productivity. When at their desk, off loading messaging and alerts to the phone is helpful for when they get up and move away from their desk the message is in hand.

The coordination of the use of different mobile devices and the desktop can be used to make a person more effective at their job not just mobile. UX designers should be oriented around the workflows and fixing the problems not around the organizations implementation teams. The designer should focus on delivering designs that optimize the workflow for any combination of devices. We are not living in a world where it is one or the other. It is the phone, tablet, desktop at work, at home and someone else’s desk.

What is the right way to organize your teams to make optimal designs for your users? Why aren’t your designers organized around the user’s workflows?

Advertisements

Being honest with your designs

Where is the line drawn between being dishonest and trying to bridge the gap between the physical world and the digital world? Where is decoration useful? Where does decoration help the user understand how to interact with the application? When is “flat” too little and “skeuomorphic” too much for the user to figure out how to get his work done?

So, contrary to what the detractors say—there is a place for decoration, and a place for material honesty. These two exist on a continuum, with decoration at one end and material honesty at the other. There’s no precise point at which a design becomes honest or dishonest. The web designer has the messy job of sorting it out.

Material Honesty on the Web by Kevin Goldman

Product Designer Impact

I have been working in enterprise software companies for the last 13 years. I started off working on a team of 4 designers for 300 developers and QA. This meant that I was working on 8 to 10 project teams at a time. If I just went to stand ups it would consume 2.5 hours per day of my time. After 5 years of working like that all we were able to do is create marginal improvements and keep the train from going off the tracks. I consider that experience a failure and so did my manager who decided to announce to the engineering VPs, infront of the lead UI architect and myself who were leading the charge, that the UI team sucked.

Peter Merholz describes this situation in his current post.

Supply and demand of digital product designers

There is a paradoxical risk when designers are in such demand. The demand reflects the value that is seen in design work. But, with such demand, most organizations have too few designers given what they’re trying to deliver. That means those designers are spread too thin, and are focused on execution that keeps the light on. Which means design isn’t being used to its fullest extent, driving not just execution, but product strategy and definition.

Because designers are seen as so valuable, they are not able to deliver their ultimate value. – Peter Merholz

I think that I have learned something that helps address this problem. Currently, my team and I work with the product owners and managers outside of the product teams. There are 28+ product teams. We identify the key problems to work on from the 5 directors of product. Of those priorities we only take on 1 or 2 projects at a time as long as they can be staggered.

We are helping define product strategy and vision. We also work on simplifying the current legacy application so that we can meet the user’s workflows and business needs. We are able to shape the direction of the product at a high level as well as at the basic screen level. The designs are then used to create the stories that guide the developers in their work.

The challenges we encounter working in this fashion shift to organizational and system architecture issues. Since the company never had people doing design in a formalized fashion before, it is a new introduction and change to the organization. The designs go across many teams at one time. Previously, most teams were self contained and now they need to work together. Architecturally, the product was not built to meet the needs of a flexible UI architecture. Every change requires a large amount of re-factoring which always becomes a scheduling consideration.

The pull exists in the organization to go monitor every development team however at this time we remain working with the product owners and managers to explore and create designs that better meet the user’s needs.

Product Manager or User Experience Designer

Steps with arrow

Should the product manager or user experience designer own and drive the product?

I have been working in the enterprise software industry for almost 18 years. The companies I have worked for have been successful and profitable for many years. In the beginning they started as engineering driven organizations and then, over time, they added product managers. While their world was competing on the features needed they were able to march forward with success. As all their competitors acquired the same set of features the current and potential customers started to recognize that complexity of use, cost of training and ability to meet their users’ workflows were increasingly important.

What should a successful software product company do about this problem? Switch the roles of who is leading to the team to put the emphasis on the workflows, tasks and users’ needs instead of the features. Here is the experience I have had with the team lead as product manager versus user experience designer.

Product Manager

User Experience Designer

Every company I have been at has senior product managers running projects within a module of the application. The senior product manager does a lot of the project management and interfacing with the engineering team. The product manager talks with customers about issues, collects information from sales and service and therefore sees the product from a feature gap basis. Instead of hiring senior product managers and more junior interaction designers at a module level, why not switch it around? Have a senior UX designer and a junior product manager. The UX designer focuses on the workflows and tasks of the user. The product manager focuses on the features and project management issues. Their basic roles do not change. The ownership and driving factors change.
As the product grows, complexity creeps in and users start to complain, a user experience designer is brought in to help. The interaction designer gets spread across many teams and is responsible for creating UIs for the product manager’s stories and to ensure the development teams are following those designs. As the product grows, shifting to have the UX designer lead the module with assistance from the product manager, changes the the team’s perspective. This focuses the team on meeting the workflows, tasks and user’s needs as the primary focus. Problems are solved in a different way. The focus changes from the feature that needs to be created to the flow and layout through-out the application.
I have not seen the process of driving UI designs from a feature gap perspective succeed in any of the organizations I have been in. Designs improve marginally with some oversight. However, the designs are still within the construct of the latest features that needed to be added to the product. This process has been successful for me working with product managers when I worked on the workflow problems across the modules and they were able to reorient themselves to this approach. When they could not change, the product continued to be built as one offs for the latest customer who had sway. It is clear that a change in focus would bring a greater deal of success meeting the customer’s needs. It is difficult to change when what you are doing was successful in the past.
The focus on features and the recency of the last customer complaints create a focus on minimal viable feature approach. The product manager figures out what feature is needed. He determines what can be done quickly to satisfice the customer’s business need. This translates to a development approach that looks to add the features with minimal impact to the existing code to avoid refactoring and extensive testing. Minimal viable feature sacrifices the long term maintainability and code reuse for the near term – just get it out the door. The focus on workflows, tasks and user needs changes the perspective to consider cross-module issues and external influences on the use of the product. This approach facilitates  simplifying and reusing similar components and UIs in the suite. Reuse and simplification from the user’s perspective translates directly to code that the developers are trying maintain and keep testable.

Although this may be a subtle distinction for many and questions will be asked on why the product manager can’t learn to do such things, the stubbornness of human behavior has consistently demonstrated that changing the behavior of a successful product manager is unlikely. So why not re-conceptualize how product teams are led? Keep the same roles but change the emphasis on which role drives the decision making.