Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Follow Us on Twitter

Archive for the ‘UX’ Category

What Does This Icon Mean? The Answer

On Monday I showed you an single icon from NPR One’s website, and I asked you ponder what you might expect to happen if you clicked on that icon, then to post the name you would give the icon in the comments.

It’s friday. So, I’ll make good on my promise to reveal the true meaning of the icon in question.

Read the rest of this post »

What Does This Icon Mean?

In his blog What Happens When You Push the Broccoli Button? Brian Flanagan brought up a great point about iconography.  A few hours later after reading it, I misinterpreted the meaning of an icon on a website. I showed the icon to Claire, a co-worker, who guessed something completely different would happen upon clicking the icon than I did, yet we were both wrong. Inspired by this coincidence, I’d like to know what you think the icon means.

Read the rest of this post »

Design for Users with Limited Literacy Skills (UXPA 2015)

mobileI was surprised to know that designing for people with various forms of literacy issues would benefit literate users. In one study presented in a session I am now attending, I learned it does! Another surprise, about 50% of U.S. citizens report some type of literacy problem. As a result, when we think about digital transformation and designing for multi-channel usage (especially mobile), there are some things we need to know to help our clients understand the wide range of users who are using their digital products, for example…

– Literacy issues are often merely a result of “situational literacy.” For example, health data is very domain specific and people are often more overwhelmed trying to understand a diagnosis, to sort through health plan coverage or to follow directions for how to take and submit a lab sample. Read the rest of this post »

The UX of Enterprise Applications – What’s So Different?

shutterstock_268845611 (1)The UX of enterprise applications has typically lagged behind consumer applications. Look at the way you order a product from Lowe’s or Amazon, and it’s click, click, click, done! That’s what consumers are used to, and it’s reasonable to expect that every digital experience will be simple.

Enterprise applications have significant differences that challenge design simplicity – a challenge that UX practitioners have been working to meet. Enterprise application development can be a paradox. Good design often emphasizes simplicity and ease of use. But how do we achieve simplicity with all the security and technical concerns, business processes, and compromises across business units to consider? These add to the complexity of the design and development process.

Below are some characteristics that differentiate enterprise UX from its consumer counterpart:

Context of use is different. Business, not pleasure. People use enterprise tools because they have to. Intranets, portals, CRM applications, order entry systems and the like are used by employees and are the only option for completing necessary tasks. Often, these tasks are complicated by required business rules and processes that don’t exist with consumer applications.

Enterprise applications aren’t “sexy.” Always consider context. Saying that a CRM application needs to be “sexy” is like saying a 90 year-old grandma’s going to the nursing home but needs to shop for a bikini first. Purposeful, efficient design trumps “sexy” every time.

Stakeholder vision doesn’t always align with user needs. A shared understanding among the UX team and stakeholders about user needs is critical. The need to gather knowledge of user tasks and processes – gathered from actual users, not user proxies or alternates – should not be overlooked. Very often stakeholders will provide input and have never or will never actually use the application. Real user feedback will provide insight so the team can have the same vision.

Enterprise applications are complex, task-based systems. For enterprise applications are largely task-driven. Tasks are often complex, involving multiple steps with multiple security checks. Multiple departments/divisions have to weigh in. Tasks are seldom isolated, so a holistic understanding of the process and environment is required.

Personas often include Super Users and Casual Users. Desired functionality and features can differ for each group. For example, with a CRM application, a sales manager might use a sales tool a few times per week, maybe once a day. A sales rep might use the system every day, 4 hours per day. And both likely use the system differently for very different tasks. Even in the same role, there are differences. Some sales reps with more accounts may use the system more, for examples.

Mobile isn’t always a given. Some tasks are so complex and involve so may steps and checks that completing them on a mobile device would be too cumbersome and time-consuming. In a recent research study I conducted for a manufacturing client, a user said “If I had to enter all of this information on my phone or tablet, I’d shoot myself. I’d never use this tool on mobile.”

Because they are task-based, it makes sense to think in terms of their simplest, most direct execution. However, context of use is key. For example, if an application is only installed and used on desktops in-house and there are no plans to migrate to mobile, there is no need to spend time and resources on a separate mobile experience.

This is not to be confused with the wider value of responsive design where mobile principles are inherent. It’s still smarter to design keeping mobile in mind, even if it is five years down the road.

Enterprise apps have to balance user needs, system capabilities, business rules and stakeholder goals. The discovery phase is key to determine use cases and common scenarios. Talking to users, analyzing tasks, understanding processes all help to set priorities for project work. What other distinctions can you share? I’d love to hear your thoughts.

Decoding the UI Architecture

With the increasing advent in SOA and RESTful based applications, all the business logic today is being pushed to the client. With numerable paradigms being present for the UI to consumes these services and create dynamic content, there becomes a need to define the presentation, structure and behavior of the User Interface.

While working with Brian Flanagan on a recent project, we came up with an architecture presentation to address this need, with an intent to help the business, customer, stakeholders and development team understand the architecture of UI/Front end development. 

UI Architecture

Presentation Layer

The Presentation Layer is mainly composed of CSS components, based out of an atomic design or BEM methodology. The CSS is typically written in either SASS or LESS (today’s most popular CSS pre-processors) and compiled to provide modular, scalable components, which is used to create the structural layer.

Structural Layer

Here, we create the html components/pages for the application, by making use of the structure today’s most popular frameworks provide – bootstrap, foundation and others, depending on the organization needs. The required user interactions are enhanced by making use of a JavaScript library, typically, jQuery. These HTML pages are then thoroughly tested for responsiveness, browser compatibility and accessibility. 

Behavioral Layer

The behavioral layer introduces the business logic for our UI by consuming the RESTful services and creating dynamic content. This could typically include two-way data binding, ajax, MVC and Single Page Applications, all rendered on the client.  There is an increasing number of frameworks to help us work with the business logic and the most popular one’s are Angular, Ember, Backbone, ReactJS among others. Note that selecting an appropriate framework is a very important task as each framework has its own pros and cons catering to different needs. 

Production Layer

Finally, we have a bunch of fantastic build tools that takes care of all the routine tasks involved in development such as compiling, minifying, compressing, package management, among others. The build tools keep a track of changes in all of the above 3 layers and eventually provides us production ready HTML, CSS and JavaScript assets which can now be integrated with any backend application.

I hope this article explains the UI architecture and the underlying processes. Is this something similar you have seen implemented in your project/organization ? Are things being done differently or do you have another perspective on this ? Do let us know below.

What happens when you push the broccoli button?

As I was getting ready for work the other day, my 3-year-old son decided he wanted to help me iron my shirt. First he wanted to touch the iron, but clearly that was not an option, so instead he settled on pushing the spray button and soaking my entire shirt in the process. Well that was exciting enough for him, until he noticed another big button on the iron. That’s when he asked, “What happens when you push the broccoli button?”

IMG_4891

No, I do not have a Veg-O-Matic 2000 that shoots out fresh steamed broccoli with the push of a button. It’s simply that from my son’s perspective, the symbol for steam looks a lot like broccoli. Now don’t be fooled, the kid never actually eats broccoli. Actually I’m surprised that he didn’t think it was cotton candy. But regardless, it demonstrates that iconography really is up to the interpretation of the user.

So how do you ensure that the icons you create will be clearly understood by your intended audience? It’s not always an easy process, especially when you’re dealing with abstract concepts, but the key is to closely define the relationship between the signifiers and the concepts they represent. There are two primary types of signifiers, iconic and symbolic. Iconic signifiers are visually representative of an object or a function. For example, a clock represents time or a calculator represents a mathematical function. Symbolic signifiers on the other hand, represent a concept in a more abstract way, such as downward arrow representing a download function.

Typically iconic signifiers perform better on speed of recognition and overall comprehension as users tend to interpret an unknown icon as having the functionality they think it resembles. However for that to be successful, the visual identifiers must be strong enough that the icon is not confused with another object, such as broccoli. In order to design effective iconography, you must understand your audience. Age, gender, culture and language are all key factors that influence comprehension.

For some concepts you may need to utilize a combination of iconic and symbolic signifiers. A good example of this is the “revisions” Revisions icon in WordPress. It consists of a clock, an iconic signifier which represents time and a backwards arrow, a symbolic signifier which represents stepping back in a process. This combination does a good job of communicating an abstract concept and providing clues about the underlying function of the icon.

When creating icons, it’s also important to think about the overall design system. Each icon should be clearly distinguishable from the others, while still working together as a whole. Keep in mind simplicity and recognition and always make sure you validate the concepts with your target audience. They are the ones that will tell you if the icon is successful or not.

Designing for accessibility does no one any favors

Book

For some time now I have contemplated, as a design practitioner, is my perception of design for users inclusive, empathic and universal? This has been nagging at me for some time. Actually it’s been calling my name, Psst. Lisa, you’re behind the curve in your understanding of designing the user experience for people that are, well, disabled.” Let me be more candid; my own perception of disabled people hasn’t been accurate, empathic or inclusive of the various impaired users attempting to access and benefit from the online world. My thinking on this topic needed a significant update, a DIY project in the making.

To start, I didn’t have an accurate definition of disabled people, nor of impairment. To my credit I had read the important book Design meets disability about two years ago. The author, Graham Pullin, raised my awareness of several issues and possibilities when designing for disabled people. For one, he helped me understand that disabled people is an appropriate expression “in the context of an environment or society that takes little or no account of impairment.” This is a troubling thought – “people disabled by the society they live in” due to the “designed” barriers and restrictions that limit participation in hmmm…life.  Read the rest of this post »

Less PowerPoints, More Prototypes

At the 2015 Adobe Summit, Todd Copeland of the National Australia Bank described how his organization is able to deliver digital experiences with the speed and velocity that customers expect. As Todd stated, “it’s a pretty simple equation: Less PowerPoints and More Prototypes. Less detailed specifications to justify business cases and more iterative customer testing.”

That “simple equation” is one of the key principles that is driving digital transformation. In today’s world, organizational velocity wins. Companies that are quick to adapt and respond to customers have a clear advantage. Those that are slow to respond are subject to digital disruption (see Blockbuster). In order to effectively compete, organizations must find ways to provide better customer experiences more efficiently. Enter Lean UX.

Lean UX abandons the idea of deliverables as milestones in favor of a progressive working model developed across multiple sprints. This is an important concept when you think about organizational velocity. Because deliverables eat up time. There is time required to create the deliverable, time to develop a presentation around the deliverable, time to present the deliverable and time to review and revise the deliverable. That is time that could be spent developing the actual solution. Lean UX enables the designers and developers to work collaboratively to establish a shared understanding without the need for detailed specifications or other paper-based deliverables. It also promotes transparency and trust, which can lead to a better solution.Lean UX Model
The Lean UX process involves 3 core steps:

  • Think: In the think stage, designers, developers and business owners collaborate on a particular problem and sketch out ideas for the solution. The goal is to get the core components of the solution visualized quickly so the development team can provide insights on the direction of the design, including feasibility. The initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction.
  • Make: Once a general direction is agreed upon, the team elaborates upon the solution through interactive prototypes. The interactive prototypes define the layout, functionality, relative importance or priority of information of the user interface and allow the team to experience the solution faster.
  • Test: Once the prototype is developed, it can be used to test the effectiveness of the design. By conduction usability testing sessions with representative users, the team can collect valuable feedback that will improve or enhance the solution. Based on the feedback received in the usability testing, the team makes revisions to the design concepts. And the cycle continues until all features and functionality are designed an incorporated into the working model.

Through this approach, a small, focused team can quickly prototype a working model that demonstrates the solution within a matter of weeks, instead of months. That difference is huge in terms of velocity, and may be the difference between meeting expectations and leaving your customers dissatisfied.

 

Designing the small details – “Microinteractions”

Dan Saffer's text

Dan Saffer’s text

Part 1 of 2

As a usability researcher it’s important for me to stay aware and informed of guidelines for designing user interactions. Also, I want to be literate about topics within user experience design. So Dan Saffer’s book Microinteractions – Designing with Details caught my attention. His text is interesting; it focuses on the importance of the small details, the small pieces of functionality within a digital design. Saffer thinks these small details are really important because they can be “signature moments” that impact the entire experience of a product. Now that I’ve read his book, I would agree. To illustrate his perspective Saffer has included numerous examples of when a microinteraction created an enduring signature moment, for example Larry Tesla’s creation of Copy/Paste in 1973, and a lackluster one, “the initial intrigue with Google + Circles fell flat against Facebook when sorting users into circles became tiresome and gimmicky.”

What are Microinteractions?

I have to agree with Saffer on the importance of the details in designing, but it’s difficult to always know which design elements are microinteractions. As Saffer would say they “are all around us, from the turning on of an appliance to logging into an online service.” And, these “small pieces of functionality,” as simple and brief as they are, can delight or frustrate us over and over with every interaction. I can think of a situation in which I experienced the feeling of frustration when I had to log into a retail site to access tracking details on my purchase. This merchant’s microinteraction “rule” wasn’t a wise choice because it sacrificed my user experience by adding unnecessary complicatedness. It could have been much easier with an email that contained the shipper’s tracking number linked to the carrier’s site. Read the rest of this post »

For Enlightened CIOs, the “I” Stands for Insight

Who’s the most important marketing person at your company? Your CMO? Someone on her team? Maybe your CEO? What about your CIO? While your Chief Information Officer isn’t likely to craft your next campaign, the impact he or she has on customer experience is becoming more direct and more critical every day.

shutterstock_234372760The reason is simple, and it has to do with insight. More and more, CIOs and their teams hold the keys to unlocking the customer understanding that designers and marketers crave. A convergence of trends — abundant customer data, demand for greater insight in defining and managing customer experiences and a growing need to empathize with a wider range of customers — are driving CIOs into the insights business. A question remains, however, in how effective marketing and IT teams will be in working together to uncover customer data and convert it into meaningful actions.

Insight into customer behavior is what separates good customer experiences from bad. Insight drives empathy, a raw ingredient in the effort to humanize technology and harness its brand-building potential. The astute use of customer insight is so vital that we include it as one of seven factors in Perficient’s CXIQ Assessment, our measure of an organization’s customer experience maturity. While every company offers its customers an experience, few understand what it takes to systematically turn customer insight into the superior experiences that lead to increased preference and loyalty.

Read the rest of this post »