I would like to introduce you to Peter Picone, Director of User Experience at Oracle. Peter’s most recent corporate position was with Oracle USA as the Director of User Experience for their Financial Services Global Business Unit. Currently, he is taking a short sabbatical from that life and dusting off his old consulting company Half-Tide Designs. He hopes that in the future, he will return to the corporate role in a similar capacity as with Oracle. With that, take a look at the hot user experience issues that Peter and I discussed.
What would you advise a graphic designer shifting into the field of user experience design?
Whether they know it or not, they are already in the field in one form or another. The visual aspect of interacting with users has always been a key motivator in any experience. I think the difference is really what skills are more relevant for different types of products and different phases of design.
A visual designer coming from the print world should already have a good foundation/feel for layout, color, white space, typography and the likes that should transition nicely to web and application design. However, they may need to pick up some additional skills in icon design or those things that making design for the web different than print
Which strategies do you use to support your end-users?
Not sure I have a really good response for this one, other than keeping a focus on the user and their needs throughout the entire development lifecycle through as many of the usual UX methods as possible or reasonable. Even in the case where the process needs to be paired back to a bare minimum of UX input, keeping the user formally represented wherever possible remains a first priority.
What are the top 3 pain points in UI that create confusion for employees who use online service software used in enterprises (like ERP, CRM)?
The top three – pretty much in any product are:
This is somewhat related to the other two, but quite often designers do not perform anything like a formal task analysis to understand what constitutes a primary user task vs which is a subtask, and how they should relate to each other in the final workflows. Quite often you will find branching in a flow at a subtask level, before a user has completed the higher level task. This is potentially one of the elements that leads to a workflow that does not follow the users mental model of how a goal is achieved, and often leaves them confused in the navigation.
It never fails – in almost every usability test I perform, someone explains that the reason they didn’t click the correct link or take the right action is because they didn’t associate the label on the screen with the concept of what they were looking for. Whether this is based on industry jargon, or just poor selection, it can be crippling to a design and yet it is one of the easiest things to correct once it is identified. This is also connected to the later discussion on the need for user research – concepts and jargon and users expectation are more easily accommodated in initial designs when they are identified through early research.
• User Mental Model vs Developer system model.
This is another fairly common mistake. In some of these larger enterprise systems it is very difficult to predict how each customer or end user is going to integrate the system into their overall workflow. With a lack of a single usage model it is up to the business analysts and requirements analysts to develop their concept of the most efficient system (the develop of system based model). While this might be the most efficient for system operation and data flow, it may not match the user or the user’s company model of how they system should operate.
How many times have you had to “renovate” your website/online solution?
It seems that renovation is a continuous process, and thankfully, many of today’s development environments (like Agile) take that into account. As much as we always think we have a good and final solution, we are always getting feedback from users, requests for changes and new functionality, as well as new marketing standards and updated visual styles to incorporate. In addition, as technology changes and it becomes easier to incorporate things like dynamic behaviors, motion based interactions, and responsive designs, as long as they provide some additional benefit, there will always be a need to rework a site or an online solution to make life easier for our users.
If you had a few key tactics to help UX designers interested in convincing stakeholders on the value of research, what would it be?
The first is usually and educational tactic. Not everyone is aware of the types and details of the research you are proposing. They may not understand the scope, the timeframe required, or the deliverable products that will result from the research activities. They also may not be aware of how early contextual types of research fit in with the overall UX process and how they could be critical in determining success criteria for later phase research and validation in terms of usability testing down the line.
In times where people have questioned whether it is worth the extra effort to incorporate UX in a process (vs. pushing ahead on cost and schedule), one of my favorite convincing lines is to ask the simple question “What’s the right thing to do here?”.
Ultimately, most people know the importance of understanding the user and getting the requirements right (and complete) before going too far into design and creation of code. They have all felt the pain of re-writing something because they didn’t understand the needs going in. As such, the motivation is already there, they just need to be reminded of it and possible repercussions of skipping it. The really hard sell version of this is to firmly make the recommendation in writing as a part of public record, and then – in private, remind them that they are going to be the ones to explain to the Exec VP or CEO why they chose to gloss over such an important step, especially when all of your competitors are investing so heavily un UX these days…
Another tactic is to start asking the stupid questions that they may have glossed over in their initial requirements gathering. As a rule, they usually don’t have a solid answer for them.
• “What other tasks might the user be doing that could interfere with how you think they are going to use the system?”
• “Who else are they going to need to interact with, and where will they be getting all the answers they need to fill in a form?”
• “Are there physical, psychological and/or environmental considerations that are going to come into play – such as using your software on a mobile device with one hand on a moving subway train, or sitting and working in a public place while entering or reading personal information – like checking a banking application?”