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 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?

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.

Communication Pattern of Effective Presenters

This is the pattern for storytelling from the most effective presenters. Nancy Duarte mapped out the pattern of speeches that did a good job delivering a convincing argument for an idea.

Ted Talk: The secret structure of great talks

HBR article: Structure Your Presentation Like a Story

Product Manager or User Experience Designer

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.

Portfolio Summary: Summarizing Non-Normal Data

We are designing the information displays for portfolio managers. In the process of understanding what information is needed we have identified from our resident portfolio managers and customers the need to get a quick overall status of the portfolios under management.

If we are looking at one portfolio there are some specific characteristics we would like to roll up and summarize. Let’s take the example in the fixed income world. If we have a portfolio of 100 securities, when we look at that portfolio summary we would like to get a sense of the spread, duration, convexity, and credit quality. When asked how they would roll this data up, the portfolio managers tell us to use a weighted average.

The problem is that the distribution of the data is non-normal most of the time so taking an average is useless. What would you do to express the overall distribution in non-normal data?

Some thoughts:

– create a plot –  it is non-normal and the distribution is irregular so perhaps a distribution plot would be useful (a little sparkline of the distribution to give a general idea)

– monitor control boundaries – upper and lower bounds with counts below, in the middle and above would be helpful (this would allow the user to see the outliers quickly)

– measure drift – positive and negative drift from a benchmark or model where you want to be at for each position and identify the drift (this may be normal but I am not sure)

It seems to me that we could come up with many much more useful and truthful representation of the underlying data than the weighted average.

Have you played around with this?

Is there an industry standard for expressing this data?

Do you have some ideas?

5 Questions to Ask for a Better Solution

Are you a business owner or product manager looking to improve the design of your product? Even if you do not have a designer on staff, you have design minded team members that can be guided with right questions. Here are some questions to ask to get your team to drive to the optimal solution.

Question 1: What is the problem you are trying to solve?

There is a tendency to jump immediately to solutions without first stating the problem. Stating and clarifying the problem itself will crystallize the issue for both the product manager and the team. Ask this question to have team members verbalize the problem.

For example, I had a project manager ask me to design an icon to put on the screen. This button was the solution he determined for the customer problem. I asked him a series of questions around the problem and it turned out the button was a band-aid that would resolve the specific customer request. The real problem was much larger. Users were not able to get their work done smoothly and they wanted to speed up a process they did frequently throughout the day.

Question 2: Who has this problem?

There is a tendency to focus solutions on the most recent set of user requests or complaints, rather than generalizing to the overall user population. This question is asking about the persona or the archetype of the user. Identifying the persona determines the persona’s needs, goals, activities, environment and how the company wants to interact with this type of user. 

For example, I had a project manager come to me for help with a specific product enhancement. One customer was asking for a specific feature. By having a conversation about the type of user this request came from, we were able to do a better job of generalizing the problem and solving this issue for a greater number of customers.

Question 3: What is the user trying to do?

Understanding the context of the interaction is the essence of user experience and product design. Everyone should be clear on the tasks and workflows that the user is doing when encountering this problem. Diagramming, story-boarding, or videotaping helps to communicate the workflows clearly to the team.

For example, I have been designing software for traders. Traders work in an information dense and noisy environment. Many traders attend to 3 to 6 monitors, multiple phones and a TV broadcast while in an open space with many people talking and shouting. The trader runs several applications with very different visuals. Each application has many moving parts: flashing data, programmed sounds and interdependent information. How do you design incoming information about a stock that is not visible on any screen without interrupting the traders current work? Knowing the context of the environment will ensure a design that meets the users needs.

Question 4: How are we going to design the product?

As the business owner you should expect many solution ideas for each problem. All possible solutions that impact the user should be sketched. Encouraging many different team members to sketch on their own will triangulate on a better design than one person designing.

For example, I worked on a project where not only did the internal team come up with sketches but so did the client. We presented and explored the sketches everyone put forth. We compared two designs to identify what worked and what did not work (do not allow personal opinions unless you are building the product for that individual). This was one of my most successful designs from the perspective of user acceptance and client and team buy-in.

Question 5: How are we going to figure out which design is going to work?

Identify the three best designs to prototype. Create and review a storyboard for each of the designs. Have the team prototype the designs on paper, in PPT, Balsamiq or whatever means that result in a quick turnaround.

For example, I use PPT to mockup and prototype the UIs. I have created PPT squares that illustrate the UI framework we are working with, which allows anyone to  prototype and edit the screens. Since interaction design requires small movements and transitions, I have found PPT very useful to illustrate small changes that the user can click through. The PPT click-through allows the user to move forward and backward at their own pace and replay the interaction over and over. I have found that some users will be able to provide feedback as to whether the design solves the problem or not. I look for trends to emerge.

The result of this process is that you will get quick, tangible feedback from users before coding has begun. Completing the process allows more members of the team to be able to accurately visualize the solution, resulting in team cohesion and better execution in the engineering stages. These steps provide a rapid means of investigating the solution space and throwing away poor ideas before time is spent coding. In hours or days, depending on the size of the problem, you come away with a more confidence in the design of the solution.

Innovation Is About Arguing

This is a beautiful explanation. Every time that I work with a new product manager or business owner I always explain that I ask a lot of questions. When we are working together, I am going to explore the constraints and boundaries of the problem. When I explain it that way they do not feel that I am just being argumentative. Continuum has done a nice job of embedding this into their process and culture. Entering cultures that do not do this is a challenge because many people are sensitive to feeling a question is challenging their work.

On the point of say “no, because,” I try to avoid “no” in many cases because it is so final. I rather say “what about …, what do you mean …, I thought it was …”

I have worked with individuals and teams where we do these 5 things and it does help explore the solutions space. It is a mindset that all team members need to have to work. For many, the suspension of disbelief has to be requested so that they can go through the process and learn to trust the questioning/arguing for the purpose of exploring the solution space.

Innovation Is About Arguing, Not Brainstorming. Here’s How To Argue Productively by Daniel Sobol

1. “NO HIERARCHY
   Breaking down hierarchy is critical for deliberative discourse.
2. SAY “NO, BECAUSE”
   No is a critical part of our process, but if you’re going to say no, you better be able to say why.
3. DIVERSE PERSPECTIVES
   This model works for us because deliberative discourse requires a multiplicity of perspectives to shape ideas.
4. FOCUS ON A COMMON GOAL
   Argument is productive for us because everyone knows that we’re working toward a shared goal.
5. KEEP IT FUN
   Our work requires intensity, thoughtfulness, and rigor. But no matter the nature of the project, we keep it fun.”

http://www.fastcodesign.com/1669329/dont-brainstorm-argue

Big Data Analysis

This article makes the case that with the increase in data, there is a greater need to make decisions on the data and therefore a need to better represent the information for human consumption and decision making.

“Manually analyzing data is time consuming but is often done in order to maintain core business capacity, operational continuity, competitive advantage and compliance. Reviewing stacks of numbers and text is not only error prone but also makes it difficult to analyze data in order to:

1) Develop or assess a hypothesis: Those managing regulatory compliance may need to consider and assess a hypothesis like Hyman Minsky’s financial instability hypothesis to protect their firm’s future.
2) Discover errors and outliers: From a risk and compliance standpoint, a firm may want to find a way to easily monitor risk exposure across a portfolio on a trade-by-trade basis and manage outliers or trades that are over certain limits.
3) Map trends: From an investment management perspective, a firm may want to track volatility across sectors or industries to capitalize on market opportunity.
4) Create categories: A valuation and risk group may want to know if it can readily quantify exposure to all counterparties by subsidiaries.
5) Make decisions: A structured products group may want to know if it can create “what if” stress scenarios and decide on optimal product selection.
6) Understand relationships, such as spatial hierarchy and rank: For energy traders, the need may be to determine if a company can manage pipeline operations and portfolio optimization across crude, refined, natural gas and other commodities.
The need to effectively and efficiently address these concerns, individually or in combination, is a challenge for many firms. Following a thoughtfully crafted method to hone the possible visualizations choices is a good way to identify the most appropriate one. ”

http://www.wallstreetandtech.com/data-management/how-to-select-the-most-accurate-data-vis/240142593
By Julie Rodriguez and Francesco Brullo

The product design sprint

The product design sprint: a five-day recipe for startups – Jake Knapp/Design Partner, Google Ventures
http://www.designstaff.org/articles/product-design-sprint-2012-10-02.html

Day 1: Understand
Dig into the design problem through research, competitive review, and strategy exercises.
Day 2: Diverge
Rapidly develop as many solutions as possible.
Day 3: Decide
Choose the best ideas and hammer out a user story.
Day 4: Prototype
Build something quick and dirty that can be shown to users.
Day 5: Validate
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.