Adapting to Agile UI

Pastel on paper by Steve Buckley 2009-2010

User Interface designers face unique challenges in an agile development environment but with the right design approach and production stream great results are still possible.

First let’s look at team structure. Agile teams are usually smaller than traditional development teams and–importantly for UI designers—the engineers play a more decisive role than in traditional development groups.

In this context, there’s a lot of variability in the role of ux. Because requirements and beta are in flux it’s just not possible to create a complete design and then hand it off to the development team. Instead there’s a fluid process that requires coordination and sensitivity to time constraints.

Just because the engineers lead the charge doesn’t mean that UI design has to take a back seat. Quite to the contrary, it is even more critical for the UI designer to establish key patterns and visual memes that will be recognized and understood by the user.

One key learning is that developers and ux look at application design from entirely different perspectives: The developer looks at the system from the bottom up as a result of the fact they have to create functional components one at a time. (I am not aware of any top-down method for development, but perhaps someone can clue me in if there is.)

Conversely, ux designers have the responsibility to look at the design from the outside in: How to surface concepts and processes in way that is transparent to he user. Software design is one field where form does not follow function.

For example, developers in an initial build will often construct a pyramid like trajectory for end users: users enter information through a series of data-centric steps before they get a glimpse of the end result.

Our role in ux is, in a sense, to invert the pyramid and allow users to literally or conceptually see the end result from the beginning so that they are motivated, and engaged throughout the process.

Image: Steve Buckley, Untitled pastel on paper, approx. 18″ x 27″, 2009-2010.

Share this article

Agile Process and UX

Patty Fabricant, Diamond Fade, 2003 Watercolor 22" x 30"

As agile methodology gains traction, challenges to adapting are emerging.

Today at any given moment I am simultaneously working on projects with agile and waterfall methodologies. As a consequence, my teams need to switch mindsets and approaches as they move from project to project. This adds an additional layer of management complexity to our workflow and communications. And a big part of it is about managing responses and expectations.

“Now, not only do we need to balance multiple accounts, working groups and projects, we also need to change the way we respond to design challenges.”

In the projects that adhere to traditional waterfall method our response usually begins with scheduling a meeting while int he agile method we immediately jump to problem-solving. The former is consensus-based while the later is improvisational.

“The agile teams that I work with are smaller and more accepting of individual creativity.”

In an agile environment, individual members of the team are more empowered to solve problems without getting approval or seeking consensus in advance. And importantly, rarely is any formal documentation required. Instead the team-member comes up with a solution, implements it and then asks the rest of the team to review and comment. Most often, the other team members will adapt their own work to the new development and integrate this into the project on the fly.

For organizations that derive revenue from change orders, account management and recurrent meetings this can obviously create challenges. In the more traditional designed and planned projects, the team is often stuck seeking approval and consensus in lengthy meetings for a new idea, enhancement or revision. Downstream there must be documentation updates.

“While part of this is a consequence of working in a regulated environment (healthcare), it is also related to the fact that the development teams are fragmented and geographically separated.”

It’s probably not possible to create using an agile method in an environment where the development and design teams are on separate continents and time zones, but it sure would save a lot of time and money.

 

Image: Patty Fabricant, Diamond Fade, 2003 Watercolor 22″ x 30″

 

Share this article

Designed in California, Built in Hell

FIlm Still from Cocteau's Orpheus

 

Inhuman working conditions within Apple’s manufacturing supply chain stand in stark contrast to the superlative usability of Apple designs. It should give ui designers and software design engineers pause—especially those of us that talk about user-centered design.

“As our society becomes increasingly focused on accessing and manipulating information and on communicating digitally, it’s very easy to lose site of the physical reality right around us, let alone on the other side of the planet.”

Right here in New York we use our iphones amid crumbling infrastructure while the best design and engineering talent is applied to the next generation of handhelds and software.

Now we learn that the sleek Apple products we’ve come to love and depend on are produced in factories with exploitative policies and dangerous working conditions, routinely exposing workers to toxins, dangerous machinery and numbingly long shifts that exceed reason.

The fact that these conditions are an integral part of Apple’s pricing structure—and, thus, their profitability—has been widely commented upon. What has not been discussed is how this implicates the design community.

Q: What does it mean to talk user-centered design philosophy and then ignore the manufacturing and supply side of the process?

A: It implies an inherent bigotry embedded in the assumptions. It would seem that we believe that users of the products are entitled to the best possible user experience while those involved in manufacturing the product are not entitled to any consideration whatsoever.

And it points out the extent to which user experience design has become obsessed with the interaction between some humans and computers at the expense of other humans and the physical world.

Public knowledge of working conditions may build and exert pressure on the industry to clean up its manufacturing act.

Physicists and basic technologists are on the path to developing ever-smaller transistors, and progress in nano-tube transistor technology is moving ahead as I write this. It is predicted that one day soon processors will be small enough and cheap enough to embed in everyday objects, allowing us—perhaps—to truly realize an intelligent world.

“Perhaps this will enable us to reconnect the world of pure information with our physical infrastructure.”

And perhaps the brilliant designers who are now working on yet another redundant mobile app will turn their focus to making our physical world more humane.

 

Share this article

Proliferate, Aggregate, Repeat: Why App Aggregation will be the Next Big Thing

Archimboldo, The Librarian, 1566

Looking at the path the internet has taken over the last ten years, a repeating pattern is emerging. The pattern starts with the establishment of a new asset or application class. It proliferates throughout the web. Then the aggregators come along and start skimming the cream off the top and presenting the best in single package. This pattern began with pages, moved on to shopping, news, reviews and downloads.

Today, with the proliferation of stand-alone applications, the environment is ripe for the next level of aggregation.

A Glimpse

An early entry into this space is If This Then That (ifttt.com).  ifttt is a meta application that allows users to build custom programs that uses separate apps as triggers and components.

How It Works

Using ifttt, you can create a task (or recipe) that automates a process that you used to do manually. For example, take a Facebook status update as a trigger to create a tweet, a new blog entry and update a photo automatically. Or, it might use a weather report or new information on an RSS feed to trigger a series of actions across personal sites, social networking pages, email or micro-blogging. While it is still rudimentary today, don’t shrug it off as just a novelty item.

Going Beyond the Individual

Consider instead how an application like this could integrate with Google’s social graph. The potential to trigger actions that are rules based, broadly social and widespread are staggering (and potentially virus-like).

While we shouldn’t underplay the concerns about security and the stultifying effect that automated messaging can have on human-based social interaction, the promise of this next phase of aggregation is beginning to come into focus.

Image: The Librarian, oil on canvas, Archimboldo, ~1566

Share this article

The Movable Feast: Persistent Social Identity

if this then that allows users to build trigger-based action recipes using open authorization


What do you get when you add Open Authorization to web APIs and then combine with social networks? The next phase in the evolution of the interactive culture.

For a glimpse of what this may enable, look no further than the logical engine ifttt.com (If This then that.)

Using open protocols for authentication, ifttt allows non-technical users to build logical arguments that trigger and execute actions. Ifttt calls them recipes to make them more accessible and they’ve done a smashing job of making them easy to understand and use. A recipe might automatically generate a twitter message when someone follows you, or update your WordPress blog when you post a status to Facebook. Many of the recipes are true time savers. While others suggest a runaway world of robotically-generated chatter.

Perhaps what’s most interesting for the UI/UX design and for anyone concerned with user experience, is how open authentication protocols allow us to carry our social identity, as it exists online, with us wherever we go.

Like the proverbial movable feast we no longer leave our friends. Instead, everywhere we go, our social network is with us.

In the same way that AJAX technology moved us away from the concept of the web as a series of static pages, open authorization moves us away from the idea of browsing. Instead we travel with our posse ever present and perhaps more importantly, ever visible to others.

Image: ifttt (if this then that) allows users to build automatic tasks based on integration of social channels.

Share this article

Pattern Recognition and Defining Users

From data to design: building a user-centered navigation  One of the biggest challenges to developing websites for large organizations is managing the needs of vastly different target audiences. Given the need for speed to market there’s a very real need to develop lightweight and rapid methods for understanding constituent audiences, what their goals are, and merging them into a comprehensive user experience design.   The questions that the method needs to answer are: 1.	How do we rapidly segment audiences in a meaningful way?  2.	How can we identify primary and secondary goals for each audience? 3.	How much emphasis should we put into satisfying user needs vs. pushing brand messages or goals? 4.	How do we serve all of our audiences needs while still keeping the result simple and easy to use?  How do we rapidly segment audiences in a meaningful way?   Audience segmentation is a process similar to pattern recognition; two individuals can look at the same information and both correctly discern entirely different patterns. It is also a function of the objectives of the initiative. Here are some conceptual ways to frame an analysis of user types:   1.	What is the objective of the initiative? Is this an application, a corporate website, a marketing initiative, a networking tool or a lightweight single-purpose app? a.	In examining the marketing site it is conventional to think about audiences in terms of brand sentiment or progress along a purchasing continuum b.	If it is an organizational website, it is more helpful to think about constituents; e.g., customer types, internal stakeholders, external stakeholders, partners  c.	For applications, users are typically defined through task analysis; what is the individual trying to accomplish and how must the system respond to the user to enable them to satisfy their needs? d.	For social networking tools, functions need to considered against to coordinates; the social platform into which it will integrate and the user’s goals  Regardless of the type of initiative, it is critical that the audience segmentation is as concise as possible. Ideally, aim for no more than seven user types. But if you run higher keep in mind that once you go on to break down the primary and secondary goals you may find that some segments are so similar that their distinction is not significant enough to justify maintaining the separation.  Photo: MAURIZIO CATTELAN, Super Us, 1998 (detail). 50 acetate sheets, 29.8 x 21 cm each

From data to design: building a user-centered navigation

One of the biggest challenges to developing websites for large organizations is managing the needs of vastly different target audiences. Given the need for speed to market there’s a very real need to develop lightweight and rapid methods for understanding constituent audiences, what their goals are, and merging them into a comprehensive user experience design.

The questions that the method needs to answer are:

  1. How do we rapidly segment audiences in a meaningful way?
  2. How can we identify primary and secondary goals for each audience?
  3. How much emphasis should we put into satisfying user needs vs. pushing brand messages or goals?
  4. How do we serve all of our audiences needs while still keeping the result simple and easy to use?

How do we rapidly segment audiences in a meaningful way?

Audience segmentation is a process similar to pattern recognition; two individuals can look at the same information and both correctly discern entirely different patterns. It is also a function of the objectives of the initiative. Here are some conceptual ways to frame an analysis of user types:

  1. What is the objective of the initiative? Is this an application, a corporate website, a marketing initiative, a networking tool or a lightweight single-purpose app?
    1. In examining the marketing site it is conventional to think about audiences in terms of brand sentiment or progress along a purchasing continuum
    2. If it is an organizational website, it is more helpful to think about constituents; e.g., customer types, internal stakeholders, external stakeholders, partners
    3. For applications, users are typically defined through task analysis; what is the individual trying to accomplish and how must the system respond to the user to enable them to satisfy their needs?
    4. For social networking tools, functions need to considered against to coordinates; the social platform into which it will integrate and the user’s goals

Regardless of the type of initiative, it is critical that the audience segmentation is as concise as possible. Ideally, aim for no more than seven user types. But if you run higher keep in mind that once you go on to break down the primary and secondary goals you may find that some segments are so similar that their distinction is not significant enough to justify maintaining the separation.

Photo: MAURIZIO CATTELAN, Super Us, 1998 (detail). 50 acetate sheets, 29.8 x 21 cm each

Share this article

From thought to design: building a user-centered navigation


One of the biggest challenges to developing websites for large organizations is managing the needs of vastly different target audiences. Given the need for speed to market there’s a very real need to develop lightweight and rapid methods for understanding constituent audiences, what their goals are, and merging them into a comprehensive user experience design.

The questions that the method needs to answer are:
1. How do we rapidly segment audiences in a meaningful way?
2. How can we identify primary and secondary goals for each audience?
3. How much emphasis should we put into satisfying user needs vs. pushing brand messages or goals?
4. How do we serve all of our audiences needs while still keeping the result simple and easy to use?

How do we rapidly segment audiences in a meaningful way?

Audience segmentation is a process similar to pattern recognition; two individuals can look at the same information and both correctly discern entirely different patterns. It is also a function of the objectives of the initiative. Here are some conceptual ways to frame an analysis of user types:

1. What is the objective of the initiative? Is this an application, a corporate website, a marketing initiative, a networking tool or a lightweight single-purpose app?
a. In examining the marketing site it is conventional to think about audiences in terms of brand sentiment or progress along a purchasing continuum
b. If it is an organizational website, it is more helpful to think about constituents; e.g., customer types, internal stakeholders, external stakeholders, partners
c. For applications, users are typically defined through task analysis; what is the individual trying to accomplish and how must the system respond to the user to enable them to satisfy their needs?
d. For social networking tools, functions need to considered against to coordinates; the social platform into which it will integrate and the user’s goals

Regardless of the type of initiative, it is critical that the audience segmentation is as concise as possible. Ideally, aim for no more than seven user types. But if you run higher keep in mind that once you go on to break down the primary and secondary goals you may find that some segments are so similar that their distinction is not significant enough to justify maintaining the separation.

Image: Christopher Wool, “Untitled” (1988) courtesy of the Broad Art Foundation

Share this article

User Testing and Intuition

Sol Lewitt Wall Drawing Instructions, late twentieth Century.

As much as I believe in user testing I find it difficult to advocate for it.

In the last few years it seems like most of our projects are on a compressed schedule that doesn’t allow for formal testing. We compensate by designing variables (A/B testing) into the launch, randomly displaying two versions of the same interface to see which one performs better. The result most of the time: no significant difference. In a few occasions we’ve conducted eye-tracking studies with essentially the same result.

Most of us can quickly recognize a well-designed interface from a poor one, can recognize the established patterns and combine (and recombine) them to form complex systems. THe result is that doing ux produces predictably usable results. This is a result of patterns becoming ingrained not only in the practitioners of ux but also in our audience who are essentially internalizing behavioral interface patterns.

What’s the most fascinating thing to me is that some of the most popular websites still have poorly designed interfaces that are extremely difficult to use (amazon, ebay, google ex-search). And what this proves to me is that the role of familiarity often trumps good design.

Photo: Sol Lewitt wall drawing instructions, late twentieth century.

Share this article

Invention, Reinvention and the Wheel

Working with my team today on a new interface that uses a horizontal transition between pages. The entire site is designed using just HTML5 and JQuery so there’s no Flash to worry about.

It’s another example of how interaction design can largely abandon the concept of pages in favor of a more responsive interface. But how did we get here?

When I was first educating myself on software design, one of the first concepts that I cam across was the idea of control systems. This generally refers to hierarchical relationships between key parts of a logical system that govern which parts of the system give out orders and which parts respond to those orders.

This is what prevents a malicious website from taking control of your computer. It works because in the hierarchy, the operating system is above the browser, and in turn, the browser software is above the website. The OS can’t be controlled by the browser but the browser can be controlled through the OS. (You launch or quit and application via the OS, not the other way around.)

From an end-user perspective, these relationships are somewhat intuitive through common convention, however from a ux designer’s perspective these hierarchies are what delineate the possible from the impossible in design.

The recent history of interaction design can, in large part, be described as the blurring of these hierarchies.

The two key factors at work in this process are asynchronous web programming and app culture. The first eradicated the concept of the web as a series of pages in favor of a dynamic display that can be continually refreshed based on user actions (vs. hyperlinks), and the second changed the act of downloading and installing new software into a casual act from what was previously a considered purchase.

Illustration: Dominance hierarchy of a single population of elephant seal males during the mating season, from From Marianne Riedman, The Pinnipeds, page 206.

Share this article

Using UI Patterns for Brands and Customers

Interior view of Hermés store showing the display of products for sale in a manner that does not invite comparison.

Most designers will agree that the most successful interface design solutions are intuitive for users while being elegantly simple.

Simple as it sounds, actually developing a design with these qualities can be challenging and elusive.

There are a number of good reasons for this:

  • The full range of functionality is not always included in the initial scope. As a result new features and functions get added-on later. This can bloat, break or simply confuse the interface.
  • Application design today is increasing a collaborative effort where project sponsors, end users and others participate in the design process. The result often betrays the fact there is no single vision for the interface.
  • Features that appeal or seem intuitive to some (but not all) make it into the final design and this can create mixed metaphors, obscure or inconsistent thinking.

While ux designers rarely can control the terms of the development process, (nor should they be) most of us would probably agree that the ux designer should take a leadership role to synthesize ideas around a coherent solution.

Using a Pattern-based Framework

To manage the design process effectively, designers need a solid conceptual framework. Without this, the design will be subject to unreasonable influence by individuals involved in the process who have a unique standpoint but can’t or aren’t willing to see the needs of the entire cohort of users.

• Using patterns allows ux designers to defend design decisions based on proven usability

• Used judiciously, patterns accelerate time to market and remove some risk

• Over-reliance on patterns, or patterns used in a cookie-cutter fashion can result in poor user experience

Why Patterns Work

Simply put, patterns work because they are in many ways the designers’ means to delivering an intuitive experience for end-users. Ultimately there is nothing intuitive about using computers other than the patterns of behaviors, expectations and visual appearances that have been established by previous experiences. By using well-established patterns, designers stand a better chance of “getting it right” than if they attempt to create a totally novel interaction design.

Balancing Innovation with Pattern Use

Developing innovative design paradigms is without doubt a critical component of the UX designer’s job. Without it there would be little opportunity for improvement over the current status quo. It can be argued that if we consistently stick to tried and true interface patterns design will become homogenous and boring—looking and behaving all alike.

By using patterns intelligently and critically it is possible to get the benefits of established patterns such as intuitive (which I would prefer to call habituated) use, ability to use or reuse existing functional components and a more speedy development process since the development team will be familiar with the functional patterns that are needed to support the UI. Slavish or thoughtless use of patterns will produce mediocre results. What makes pattern use valuable is the knowledge of when to use them and when not to.

Patterns and Customer Experience

Every pattern exists to solve a problem. Whether is to navigate a directory, conclude a purchase, register with a site or publish a comment, UI patterns build on the experiences that users have previously encountered completing similar tasks so that their ability to complete that task is consistent with their expectations. But a pattern is more than just a layout arrangement: Patterns exist as much in the end-users mind as in the display. No pattern can exist without end-user participants who have a cognitive memory of the pattern.

Breaking Patterns to Build a Unique Brand Experience

Consider for a minute what makes a particular brick and mortar experience unique and remarkable: Compare for example shopping at luxury clothing store vs. a local potter that makes handmade ceramics. Both stores offer unique products that can’t be easily obtained elsewhere and both have repeating patterns that we might refer to as:

• Enter the space

• Review/compare items for sale

• Get help selecting an item

• Purchase item[s]

• Comment on the experience

• Wrapping

• Leave the space

We’d all probably agree that the patterns repeat but we also know that the experience can be dramatically distinct. Part of the success of both of these sorts of businesses goes beyond the quality and choice of products but is also tied up in the customer experience.

Luxury brands must reinforce exclusivity and brand consistency. This is usually communicated in high design standards and perfect craftsmanship in the store facility and presentation of goods, excellent customer service with a high sales associate to customer ratio and attention to detail such as packaging, signage and physical appearance of personnel.

The local potter is arguably just as reliant on customer experience for business success but of a completely different type. Customers will probably expect to be greeted warmly and informally upon entry, perhaps by the potter herself. The wares might be displayed within easy reach on simple unadorned shelves. In keeping with the handcrafted spirit, the facility would likely have a handmade feel.

Breaking Patterns to Give a Unique Customer Experience

In the interactive versions of these businesses there are places where the common patterns can be leveraged “as is” and other places where they need to be modified or broken to conform to the unique customer experience that is consistent with the ideals of the particular business.

The luxury store might, for example, eliminate the pattern Compare Items because purchase of a luxury item is usually not driven by comparison or by cost and providing the functionality might actually undermine the brand.

By contrast, the potter’s store might focus product selection directly on cost since their customers would be purchasing gifts with a predetermined budget in mind.

Patterns Resolve Problems

Patterns success depends on how well it solves a problem. Pattern usage depends on how common the problem is encountered. It all comes down to understanding your audience and brands so you can apply patterns judiciously.

Identifying user tasks in the context of brand experience is a thoughtful task that should drive the identification of candidate patterns and the ultimate web of patterns that you employ in your design.

Share this article

Pattern Languages and Social Transmission

Pole Barn Construction

 

 

Christopher Alexander’s Timeless Way of Buildinglays a phenomenological foundation for pattern making in the real world that is easily adaptable to interactive patterns in the digital space.

Patterns, according to Alexander, are similar to good syntax: each pattern to be valid conforms to a specific set of rules, in a fluid but demonstrable way. One example that he unpacks is the patterns associated with a New England dairy barn. Why is it that each barn is immediately recognizable yet unique? This is explained by the fact that each builder (who are typically not formally trained as architects) reproduce patterns whose rules have been previously established and communicated socially and culturally. One pattern is the general relationship between the width and the length of the overall structure; another is the relationship of a cow stall with the posts that support the roof; yet another is the presence of a central aisle for hay storage and distribution.

Much building (whether architectural or digital) occurs without formal design or planning. This is increasingly true today under time-to-market pressures as well as the influence of contemporary development processes that can transfer the role of user experience design from the designer who has formal training to a group process that includes participants with diverse backgrounds and often no formal training in design. The same has been largely true in architecture as well: farmers, homeowners and other informal building has characterized much of architectural history.

Patterns don’t need to be formally documented because they’re internalized by the people who use the end product–the people who live in the structures that are created. Despite this there’s a lot of activity around formalizing pattern collections for UI designers, some of them quite nicely done. The challenge with a pattern collection is that patterns are tied to experience and experience is constantly evolving. Part of the interesting thing is how each instance that leverages patterns in architecture execute them just a bit differently in each instance. And here’s where architecture and interface design part company: Each building exists at a unique geographic site with unique traffic patterns, exposure to the sun and elements, topographic conditions, etc. Software by contrast is running a relatively small, discrete set of operating systems and devices.

Share this article

Usability is a Contemporary Mythology

Milan Kunk: How we adapt to machines and compuers is anything BUT intuitive despite the a=obsession with the term usability

How we adapt to machines and computers is anything but intuitive despite our obsession with the term usability

Recently I have spent quite a bit of my personal time helping people look for jobs. Call it my contribution to the failing economy or just the fact that I hate to see single moms on the street. At any rate, as you might guess, my first point is to help friends negotiate professional networking sites and to generally make their profiles visible to the companies and recruiters that are seeking to hire people with their skills.

For those of us in information technology, advertising and other digitally aware industries, this is a no-brainer and generally understood. However it is not the case for many people who work in other fields such as education, healthcare delivery, and social services.

It is a constant source of surprise to me how many people have no clue how to use social networking sites to their professional advantage despite the fact that most of them are regular users of facebook. After spending time walking them through steps such as taking and uploading photographs, adding biographical and resume entries and creating keyword sets a single observation has emerged: It’s all about how you handle frustration.

We are all confronted with new interfaces that are challenging and disorienting. It is part of the process of UI evolution that new patterns and paradigms are introduced and before they can feel intuitive they must be learned.

There is nothing intuitive about interacting with a computer. It is all learned behavior. Systems can feel intuitive, but that’s because their conventions conform to a pattern that has been previously learned.

In fact, we are all learning and relearning how to interact with machines all the time. We are constantly updating our knowledge, expectations and sense of normalcy. Once a new pattern is introduced it must be learned before it can become internalized: similar to muscle memory that is experienced by a violinist who intuitively knows where to depress a string to get the right tonality.

What does vary is the way we adapt to new interactive patterns. Here are two examples of adoption and resistance to change:

• Blackberry user has adapted to using an input keyboard that is tactile and refuses to move to a touch screen interface because they have become accustomed to feeling the keys in their finger tips and cannot easily adapt to a visual-only feedback system inherent in the iphone and android model of text input

• Website user is accustomed to finding a particular function interface, such as a button in a particular place. If, as a result of redesign, the button is moved, they become agitated and frustrated when they need to interrupt their task to find the new pattern

These examples point out two distinct classes of user resistance: The first is based on an established pattern of feedback (in this instance it is physical but it could just as easily be visual or audio). And, even though I am no fan or Blackberries, it is completely understandable.

The second example is more interesting. It is about a tolerance for interruption and constant adaptation to new behavioral patterns (vs. physical feedback).

What I am positing here is that how a user responds to the interruption of a task is a good predictor of how well they will be able to adapt to new technology. A user that is able to pause and switch focus from the task they are trying to accomplish to the means by which that task is attained and then back to the task itself will be able to learn the new UI pattern. Other users find the interruption to be intolerable will find it frustrating and may interpret the challenge of having to change focus as a direct threat to their goals.

What this points to is the fact that all of us are constantly adapting to technology. As my tag line says, technology changes what it means to be human. Our reactions, interpretation and behaviors are formed in large part by our expectations of what results from our actions.

I think it fair to say that nothing on a screen is truly intuitive. Particular designs just seem that way because they incorporate patterns that we are accustomed to.

Share this article

Hootsuite Impressions

Hootsuite interface elegantly combines OS conventions with that of web-based browser UI to resul tina new, transitionary state.

I just started using Hootsuite as an indivdual user. It does an impressive job of providing an extensible platform to aggregate social network activity across channels for individuals and presumably for smaller more agile marketing and PR organizations. The web-based ui design is among the newer crop that straddles browser-based aesthetics with client app standards. (If this sounds like jibberish, just think of Panic Software’s application Coda, which, like Hootsuite mixes user interface conventions from both operating systems and browsers. The result is a new transitionary state that, like mobile apps, mixes web and application standards to produce a result that feels as responsive as a resident app while pulling data from the cloud in real time.

OK now the downside. The application is still way beta with bugs galore. This is excusable except for the security issues it brings up and the fact that it is extremely powerful in terms of its ability to ramify your message footprint. One false move (intentional or no can wreck havoc).

Share this article

Why Not Balsamic (Not a Question)

Balsamic is a cool applicaiton but that doesn't stop me from hating it for all the standardization it imposes on the UI design process. Plus the fact that people who have no imagination or understanding of UI design can create acceptable UI designs that often do more harm than good to the process.

Turn back the hands of time, way back to the early days of the dot com boom. Web design in those days was devoid of templates real and imaginary. End users had no expectations and web interfaces ran the gamut from the audacious to the beautiful to the idiotic. Any new project was a chance to establish a new paradigm. And all bets were off.

Keep in mind that in the early days, web browsers were advancing and leap-frogging each other with a rapidity that made any design essentially obsolete within six months to a year. And even if it didn’t become obsolete, innovative new UI features, such as mouse-over effects, expanding menus, etc. were strong motivations for web sponsors to invest in redesign efforts.

I still remember vividly the ABC News site of the late nineties that featured the navigation on the right side of the browser. Eureka! More people are right handed, therefore this is a more convenient design. (They’d designed it to remain in sight regardless of the size of the browser window.) I was busy sharing the interface with my clients and team-members until one day soon after its release they flopped it back the left side, just like every other website.

It was a milestone day, like the day your favorite corner store closed and was replaced by gap or a starbucks. The day that conformity kicked in and a reign of standardization began.

Which leads me to my complaint about applications like Balsamic (For those of you who aren’t familiar, Balsamic is a template-based tool that allows people with no discernible visual skill to create UI mock-ups by arranging pre-made elements such as buttons, navigation tabs, form elements, etc.)

Balsamic has, depending on your point of view, opened up UI design to anyone with an interest, empowered sponsors to get hands on in the UI development process, or rendered the skilled UI/UX designers’ role irrelevant.

Perhaps it does all three of these things. But from my perspective, the larger issue is that it reinforces a standardized approach to UI design that will stifle UI innovation and further limit the kinds of interactions that we can invent or imagine.

Creativity is an essential component of innovation. And in order to remain relevant, designers must prove their worth by demonstrating true innovation, elegance and usability in the interfaces they envision.

Share this article

Bifurcate Me (again)

Rats in the works, here pictured, the front end developers and creative staff working like the Dickens to complete twice the work as befoer in the same amount of time! Technology is supposed to make things easier for us--not more difficult and time-consuming, right? But expanding coverage to mobile, tablet and for God's sake now the Kindle Fire is going to make the creative and user experience teams jump into a lake. That is, of course, if they aren't put out to pasture by lesser-paid equals in other continents.

Disappointed once again by the false promise of responsive design, CSS and syntactic design.

Our current project is nothing but a content-driven website–not an app or form-driven experience. So I wonder, why is it so difficult to create a mobile instance? Why is it that we need to create an entirely separate instance of the site? My goal was to implement the site using responsive design best practices; using device detection in combination with separate style sheets. But alas nothing is really quite so simple.

The developer team tells me that the time required to make a single set of files display correctly across devices will be so much greater than just creating a second set optimized for mobile.

But I know that doesn’t take into account the time and coordination required to maintain two separate sites down the road: when there’s a copy change, a new graphical revision, personnel changes, press releases, etc. Every one of them is going to require that each change be made twice and then edited and proofed. Everything times two. There’s got to be a better way.

I’m told the reason has to do with the fact that our site integrates JQuery and that means that once we start implementing across devices it’s going to get very buggy. I believe that too. But I just wonder, when’s the efficiency on cross-platform compatibility going to kick in on this?

Share this article

Recover, Recoup, but Don’t Redact

Consultants and agency geeks all know that preparing for a new business presentation is part strategic brainstorming, part marathon and part mind-reading. The truth is that no matter how much you know about the industry and the players you never really know what they are looking for. Requests for Proposal (RFP) documents are notoriously obtuse (they are designed to extract information from you). The onus is on you to do the research and come up with your own hypotheses.

Ultimately, the only course is to propose what you believe is right for the assignment. That means clear, measurable objectives and concise explanation of how you came to your conclusions.

Your job as a presenter is, like a good author, to bring the audience into your world–your way of thinking–and allow them to come to the same conclusions that you’ve arrived at. You can’t do that by preaching. The trick is to present your ideas with conviction and a clear rationale.

There’s always the chance that someone in the audience has already made up their mind before you arrived. They may have decided that they prefer to hire one of your competitors for any number of reasons. Alternatively, they may have another approach worked out in their own mind and are just looking for the agency whose presentation most closely aligns with their own thinking.  This is why you need to build your argument like a lawyer addressing the jury. You need to build your argument on a strong research-based foundation, then present your hypotheses and finally point to examples or best practices to convince them to go in the direction you recommend. Your passion needs to be grounded in reality and needs to built from the ground up.

Share this article

Code and Fix My Waterfall

Today I gave an informal talk on development process models. I started by explaining and contrasting waterfall method in contrast to the code and fix approach. Most of the people in the room had never heard of either of these terms which was surprising considering that they are either in project management roles or part of an interactive creative team.

What became apparent through the discussion was how we use a defacto code and fix approach for all of our internal projects and a pretty sequential waterfall for all our client work.

The real question is, how much of this has to do with formal reviews and how could that change?

Share this article

Agility and Regulatory Reviews

On Your Mark, a 60 something foot party boat docked at Haverstraw Marina went up in flaames about a week about in the beginning of Spetember and just a few days after Hurricane Irene hit. The boat was up for sale for the previous 2 or more years and so you can speculate as to the cause o fhte fire. The boat sank in palce and had to be hauled up with a humongous crane. THe boats on either side and even a few slips away were damaged by the heat. Compass housing melted, sails got toasted. It was nasty. Add this to the fact that the river is filled with debris and mud as a result of the hurricane and it is not a pretty site.

As I write this it is late on Friday afternoon in early September and we’re rushing to put the final touches on a small website that needs to go live today. The site was on staging earlier but routine QA led to conversation and conversation led to critique and finally we decided to make some last minute improvements. This is not at all unusual for most development groups but it occurs to me that this kind of agile revisioning is virtually impossible in a regulated environment. It is really refreshing to be able to rapidly change up the copy, revise the style sheet and swap-out an element. In most of our work, the review process means we need to lock things down sometimes weeks or months before launch. I don’t mind the wait but what I do mind is the feeling that you are married to a creative solution for so long. Because, as all creatives know, there’s always something you can improve on but sometimes you just don’t see it right away.

Share this article

Complexity and Interaction Design

Ease of use often has as much to do with how familiar users are with the interface pattern that’s being used as with the overall simplicity.

For example, one of the most poorly designed interfaces I use is the parking meter machines in New York. The machine is incomprehensible the first couple of times you use it. There’s too much information, the steps are numbered but they are presented out of sequence so they are very difficult to follow. However, now that they’ve been in market for a while, people are used to them and if you were to change it up–even to make it simpler to use– you’d probably trip people up because of their familiarity.

Same is true of screen-based interactions. Take Amazon or Ebay, two of the worst offenders. Of course they could improve the interaction for check out but their user base is large enough and familiar enough to grandfather the poor design.

Also as Einstein famously said, there’s such a thing as getting “too simple.” iOS has a number of areas where simplicity has trumped clarity. The result is that users have to poke around looking for how to turn off wireless, turn on location services, or switch random play off.

Our job is to present things as simply and as clearly as possible, but not at the expense of functionality. Looking simple isn’t the same thing as being simple.

Share this article

UX: Are You a Pattern-maker?

what it means to be agile? what the agile method feels liek? muddy, dirty, roll up your sleeves and forget about best practices. we used to call it code and fix. agile is very similar.

Is UX design still a skill that requires specialized knowledge or has it become a popular craft that practically anyone can engage in? If it is still a skill, has it become numbingly unoriginal–just the assemblage of patterns from a catalog?

  • Pattern-based thinking has become a standard approach resulting in more sameness in UI design. Familiarity has trumped innovation and simplicity (what users already know is easier for them to adopt)
  • Mobile has spurred an increased integration of OS elements, functions and patterns into design. This is radically different from browser-based application development that was much more of a one-off
  • New template-based software like Balsamic enables team-members with no training to develop pretty clear-looking wireframes in half the time that it takes using Omnigraffle or Illustrator
  • The vulgarized version of Agile method means that everyone is involved in the UX design process, regardless of their expertise. This is not necessarily bad, but can result in irrational design decisions

What this means for the UX design profession will be the subject of my next installment.

Share this article

Pharma: Head in the Clouds

Thinking today about cloud computing and how the successful marketing of the concept has impacted my clients’ beliefs and expectations.

Software as a service and cloud computing is on everyone’s lips but it is surprising how much confusion there is about what it is. This is surprising considering how much good information is available on the topic. Perhaps it’s part of the downside of the successful marketing campaign around the cloud: non-technical clients seem to think it’s something new despite the fact that its been around for a long time.

Meanwhile in the healthcare industry, cloud computing represents a major challenge to the existing infrastructure that’s used to house and manage patient data. Pharma has gone to great lengths to ensure security, hygiene and compliance around this sort of personally identifiable information and it will take more than a marketing campaign to change existing relationships between database vendors and IT departments.

From a design and production perspective the implications of cloud computing are huge: especially for those of us involved in one-to-one marketing and dynamic health applications. Whether we design our applications for a web services/cloud model or for a traditional model will significantly impact design. Today that means applications that require data storage such as tracking tools and health diaries that will benefit from seamless access to data across disconnected wireless devices.

Share this article

Protecting Privacy on Remote Health Applications

Mobile app dev is setting a general UX standard for mobile security but we need a protocol for health apps

In the world of mobile app design it is the operating systems that are setting the user expectations for mobile security. This is because the OS are so closely tied to the design and by extension to the user experience. This could be just fine for most applications but we probably need a more specific protocol for health applications that store or transmit personal health related data.

For example, should these apps have a timeout due to inactivity? Many users do not leverage the built-in automatic logout that comes with the OS. If so, what is the trigger to log a user off? Is it a time delimited period of inactivity? If so, what’s the correct duration for an automatic timeout on a healthcare application?

Banking websites log us out after 5 minutes of inactivity. The same is true for most web-based applications that handle financial transactions such as those found on credit card and investment management websites.

When it comes to health applications HIPAA rules are generally applied (even for those sites that are not associated with insurance). And, of course, each client organization has its own internal privacy guidelines that need to be adhered to.

But remote, portable and embedded applications change the equation for this significantly. For example, how will symptom monitoring devices or related mobile applications manage security in a wireless world? Especially challenging when the application is always on or nearly always on.

One option will be to replicate the log-out due to inactivity model that has been adopted in the web space.But the implications of this need to be examined against the need to confirm trigger-based functions, such as alerts. What may be required is that blinded notifications display to the user for their confirmation without revealing any sensitive information.

Like shared public computers, mobile and embedded devices also present risks for unauthorized use and unintentional sharing of sensitive data.

Share this article

New in Pharma

waiting as envisioned in this production of waiting for godot...

According to FDA regs, you can only describe a product as “new” for six months following approval. Good and clear enough but what about educational and user-created content published online? We’ve come to expect new articles to mean new, as in the last 24 hours–max. But with pharmaceutical companies requiring regulatory approval of all published materials, new can take on an entirely different meaning.

Now that the age of product websites (i.e., brand.com) are on the wane in favor of less brand-centric, more credible endeavors, we’re seeing more and more sites aspiring to community and blog status. But wait! Despite the design conventions, the site content still needs to move through regulatory approval at a snail’s pace.

It’s no secret that design conventions set expectation and when those expectations aren’t met it can send the user experience down the tubes. Take this scenario: pharmaceutical company wants to build an online community site to support a widely dispersed rare disease community. The site looks and feels like a community site with chronological postings and a blog look-alike. But all the postings are months old and premeditated. When site visitors attempt to make postings on their own they shoot their text into a three to six month oblivion with no knowledge if it will ever get posted or not. Not the best user experience.

What this really calls for is a two-tiered system for regulatory review: one for branded promotional content and the other for legitimate non-commercial speech in the hosted sphere.

Share this article

Design Challenges with Agile Prototyping

I love these mobile app stencils not only because they work so well but also because they remind me of the stencil kits we used in shop class eons ago

In the rush to release mobile apps and the proven success of rapid prototyping its no surprise that design has had to adjust to an agile methodology. This also means that the project sponsors are far more involved in design decisions than ever before.  It is in the nature of mobile design to rely on the OS far more than in browser-based application design. This implies (and demands) full integration of interaction design with software development in a way that hasn’t really been popular since before the emergence of the web.

Not a bad thing if you ask me.

Share this article