Posts Tagged 'design language'

On Dropping the Adjective Before Design

Dan Willis, also known as @uxcrank on Twitter, gave the third keynote at Midwest UX in Columbus, Ohio (slides available here). Discussing how we artificially break down our profession, Dan encourages us to take the adjective before design in our title and drop it. During Q&A, Joe Sokohl (@mojoguzzi) challenges this direction, stating we need the adjectives. Joe points out that there are differences between fashion designers and web designers, architects and automobile designers, and we need the adjective to understand what type of work we do. Due to time, the conversation between Dan and Joe was limited. I leave my additional thoughts below.
Continue reading ‘On Dropping the Adjective Before Design’

Advertisements

Treat every presentation like your first

I am nearing the end of Phase I of a sizable project with a client that, for the sake of simplicity, we will call Goldstar. Last week I presented my design concepts on Tuesday and had a pre-final presentation meeting Friday. In my mind, Friday was to review changes to the designs, new implications, and to obtain buy in from the core team before presenting to the larger audience. Assuming the audience was familiar with my work to date, I jumped right into the new designs and omitted the back story. The meeting immediately flipped and I was caught back pedaling, explaining design rationale and process – something I had wrongfully assumed the audience was familiar with. How could I have avoided this? Treat every presentation like your first.
Continue reading ‘Treat every presentation like your first’

Persona Skeptics…

I recently came across this post on ixda.org discussing the validity of personas in the design process. At first glance, I agree with the message. Digging deeper and reading Dan Saffer’s 2006 article about personas, I agree that the majority of personas are fibbed but I disagree in that they have no place in the design process. Trained as an industrial designer before focusing on interaction design I have created more than my fair share of fake personas. i have used friends, family and past experiences to create my ideal users. Though I agree these should not be used for the design process, I strongly defend their use in the overall span of a project. Instead of arguing right and wrong, I argue there are two types of personas, functional and influential.

FUNCTIONAL PERSONAS
Functional personas are defined as archetype users that drive the design process. This is what Saffer and many in the industry expect to see why the term persona is tossed out. Based off of actual research, functional personas are one possible tool that remind us who we are designing for and what their goals are. They are the power user, the dabbler, and the curious critic.

INFLUENTIAL PERSONAS
Influential personas are a different beast altogether. More commonly used, and mis-labeled as traditional personas, influential personas are meant simply to engage upper management, marketing and other business-minded stakeholders in the value of a product. Influential personas should not be used to drive the design process and similarly do not need to be based off of genuine research. Ideally I see influential personas being used for spin-off projects after proper research findings have been established. In this way, the main project is complete and we ask what story can we sell with a new feature or product. We already know the users and simply want to put a face to the ideal customer. Here influential personas take less time and energy but support the designer in building empathy for a user and buy-in for a product.

With functional and influential personas defined, it is easy to see how the two blur. Once developed it is easy to use influential personas in the design process. I stress the importance of avoiding this though as that is when the violation of design occurs as described by Saffer.

Why Design Communication Fails

This past Tuesday the new director of the Human Computer Interaction Institute at Carnegie Mellon organized a local alumni meet and greet. Part of the evening was spent discussing opportunities to update the now fifteen year old curiculum. A lot of the evening was spent simply discussing the field of interaction design.

One common thread through all the conversations I heard that evening was: what do we call ourselves? This is an interesting question as the field of interaction design embrces titles such as interaction designer, web designer, developer, user experience designer, human factors analyst, information architect and more. This disconnect between what we do and what we identify as is just the tip of the iceberg with failed design communication. The field of interaction design has grown out of a intermixing of design, psychology, and computer science. As professionals from these primary fields brand their work they adopt language from their former training and experiences.

It is here that design communication fails. With so many fields and backgrounds contributing there is no single all inclusive or correct glossary of terms. Everything is contextual an referential and sometimes built off of circular logic. Ixda.org has a recent thread offering a digital wiki would help remedy the problem at hand. I belied that us just a start to the solution.

The problem of communication does not exist within our field. Experts of all professions make their own context specific lingo and interaction design is no different. Instead there has to be a movement for a cohesive dictionary when communicating to non-designers. In order for design to be implemented there must be interest. That only comes from an undertanding of the value of design and the product offered. We as a discipline are effectively shooting ourselves in the foot by not standardizing our public face. You can argue the chicken and the egg here but I truly believe intractipn designs public face needs to be smoothed over and not the communication between practitioners.

When do names catch up with technology?

The carriage became the horseless carriage and is now called the automobile or the car.

Cellphones are slowly going through the same transformation. As technology changes the actual system no longer exists. Cell phones are being called mobile phones or mobile devices on a more frequent basis. This is an appropriate transition considering fewer and fewer calls are made using the cell technology of the early eighties.

Still on the plane today the pilot asked that all electrical devices be turned off including cell phones. This prompted this thought knowing that mobile phones do not interfere with plane signals. Believe me, I am glad people cannot talk on phones in airplanes. It does make me wonder though when society catches up to technology.

At what point will airlines no longer refer to cell phones? Is it one final technological leap we are waiting for or is there a social tipping point when terminology changes. What is the needed saturation point for technology’s appropriate or correct term to make it into the mainstream?

Intuitive versus Logical – The Blackberry Strom Keyboard

When I posted my initial review of the Blackberry Storm a week ago, I mentioned I was dissapointed with the interactions needed to show and hide the keyboard. The system as I interpreted it required a single touch to call the keyboard to the screen and three steps to hide the keyboard. Since then, I have learned a second method to close the keyboard:

Simply swipe in a downward motion across the keyboards overall target area and the field will dissapear.

When I first read about this feature I thought “wow, how intuitive”. In closer inspection of the interaction, I realized I mislabeled the interaction. There is no affordance (to add to the abuse of the term) that the keyboard closes at all. No virtual hinges, no hatch marks or trianges to denote any type of interaction. It was with this in mind I rephrased my discovery to “wow, how logical”. The entire interaction makes sense after all – once it was shown to me. I thought “how could I miss that?!” If I were a random user I would have accepted it as a great solution and should have known better.

That is not the case though. I do know better and it shouldnt be the user who feels responisble for ‘you shoulda known’. The only reason I discovered the interaction is because, in my waiting for the device to actually release, I read every piece of documentation I could get my digital hands on. That is not normal. I never read manuals and I would be shocked if the majority of people read much of them at all.So yes, I will admit in the UAR world this is a minor problem with easy learning and little persistence. But the feature is so rich that it should be learnable.

So to return to the subject of logical and intuitive. Logical interactions are not a replacement for intuitive interactions. A system is no good if the user spends half of their time not knowing about a rich interaction. (based on the two year contract for mobile phones) There should always be some way to display action and direction of functions, even if it is easily learnable. I want to clairfy, this is not an excuse for ad hoc overbearing labels, tags, and callouts. The system should intead talk with the user and not to it. To interact in a subtle way without additional clutter (remember combinatory explostion from psychology?) It is the challenge of interaction and interface designers to find this balance and I challange RIM to offer an alternate solution to this simple design issue.

When does Feature Creep Hit?… the iPhone

Feature creep, the swiss army knife effect, Ockhams Razor. Call it what you will. They all discuss the same thing – simplicity – the fact that the simpler and more elegant solution probably wins.

So what is the threshold, or tipping point, for feature creep? How is it measured? When does a tool begin to lose its utility due to an overload of function?

When the iPhone was first launched is had 18 (?) applications. There was no third party application store and firmware updates were to fix first generation bugs. Jump ahead ~18 months and we have pages of applications and Firmware 2.2 releasing mere weeks after 2.1. Looking through the App Store, I see over half a dozen instant message applications, more RSS feaders than there would be sites in my own, and multiple applications offering the desired copy and paste function. The firmwar updates are now adding features to keep up with the market, on top of their functional advances. So when does this overabundance finally hit the point where the iPhone is no longer graceful in its function and it is instead another clunk tool? I recently came across the sit of http://pleasefixtheiphone.com/ Many of the requests are known and have been addressed, or at least acknowledged, by Apple(notorious copy and paste push, camera quality.) Others simply cause me to shake my head and wonder. Feature requests range from drop down menus to zooming into video playback, to being able to use the iPhone as anything and everything under the sun.

This makes me think of the story “if you give a mouse a cookie”. Well, Apple has opened pandoras box with the AppStore allowing third party developers to fill the gaps Apple is leaving open. Some Apps have been refused only to appear in a Firmware update. That leads to the main question of when should a feature make the leap from third party development to a native feature? When does Apple daw the line and what will set the iPhone apart from Windows Mobile and Blackberry devices when that time comes?

So I do not offer a solution here. I only ask the question that feature creep is about as unavoidable as Kleenex being synonymous with tissues and when it happens, how do you keep your product separate from the mass?


My Work

What I Tweet

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 7 other followers

Advertisements