Category Archives: Customer Experience

You Are STILL Not The User

Leave a reply

 

This week I am reprinting a classic from the Nielsen/Norman group about the dangers of using internal consensus as a stand-in for actual research and testing. This is a classic mistake, usually committed by product people who have backgrounds in sales and marketing instead of research and/or engineering. But it is not limited to them: even experts in user-centered design can fall prey to this effect. It’s important, then, to make sure that assumptions about a product’s use and functionality be continually validated by testing and observation.

 

Post originally written by NN/g researcher Raluca Budiu on October 22, 2017
By now you probably have heard the phrase “you are not the user”  — it’s become one of the mantras of user experience, and rightly so. All our work as UX professionals stems from the assumption that we are different from our users. Artifacts that are right for us are not necessarily right for our users: we can’t judge user-interface quality based on whether we like a design ourselves. We need to learn how to create systems that are right for those who will actually use them.Assuming that you are your user is a fallacy that is ingrained in the human mind. It even has a name in social psychology — it’s called the false-consensus effect.

The False-Consensus Effect

Definition: The false-consensus effect refers to people’s tendency to assume that others share their beliefs and will behave similarly in a given context. Only people who are very different from them would make different choices.

The false-consensus effect was first defined in 1977 by Ross, Greene, and House. They showed that unlike scientists, “layperson psychologists” (that is, all of us who are put into the position to guess how others would behave) tend to overestimate how many people share their choices, values, and judgments, and perceive alternate responses as rare, deviant, and more revealing of the responders.

Ross and his colleagues ran a series of experiments in which participants had to estimate what percentage of people would make one of two choices: for example, what percentage of people would choose to contest a speeding ticket in court versus just pay the fine. After they made their estimate, participants disclosed what they would do in that situation, and also filled in two questionnaires about the personality traits of those who would make each of the two choices. The researchers discovered that participants expected (1) that the majority of people would make the same choice that they made (e.g., pay the ticket), and (2) that those opting for the alternative would have different, more extreme personality traits than those opting for their choice.

We tend to assume that our next-door neighbor has voted for the same candidate that we did in the last presidential election. Only someone who is very different from us — living in a completely different part of the country, from a different socioeconomic class, with a different education — could have voted for the other candidate. Or so we think.

These assumptions are natural. The human mind makes inferences based on one or few examples: if our ancestors were attacked by a wild beast, it would make sense to assume that the beast was dangerous and stay away from it even in the absence of other examples.

Generalizing based on the examples available is a called the availability bias and is a type  of cognitive bias. (Others include negativity bias, loss aversion, narrative bias, and framing — which is a type of priming.)  It is often a source of stereotypes and overgeneralizations. As my yoga teacher put it, with those Eastern European roots, I should have no problem with back bends — as if all Romanians were Nadia Comăneci.

Why You MUST Test

Much in the same way, we, designers, developers, and UX researchers assume that people who will use our interfaces are like us. We have one example of someone using the interface: it’s us. And maybe our colleagues. And we make generalizations based on that example. So only someone who’s stupid or very different than us could actually fail to figure it out.

Wrong. We are wrong believing that, but it’s important to understand that we are no worse human beings for doing so. It’s deeply weaved into our nature to believe that others are like us.

So what’s a fallible human being to do? And how about a fallible designer or software developer? The answer is simple. Learn about this bias. Acknowledge it. And then do something to overcome it. When it comes to user interfaces, the answer is simpler than in other avenues of life: Test. With real users (not your colleagues).  Know who your users are and how they respond to your designs by watching them use these designs. Don’t make assumptions.

UX researchers are also subjected to the false-consensus effect and the availability bias (and to many others ). Much of our qualitative work involves looking at a few users and one design, and then making inferences to other similar, but not quite-the-same situations. Or applying heuristics and the knowledge that we’ve acquired to new paradigms. It’s important to understand that these inferences can be biased — we may be wearing blinds. Often what works in one situation may not work in others, and vice versa.

Acknowledge your vulnerability and establish checks. Don’t validate; instead investigate. Study with your actual target users whenever the slightest doubt is involved.

How can Agile and UX play well together?

Leave a reply

kinder-playmates-7

Over the past few years, I’ve been a lead UX designer in an Agile environment. To clarify what I mean by this, I’ll define Agile as a specific development framework designed for rapid iterations of functional software. This is accomplished by the use of two-weeks sprints where developers will tackle a particular user story with a chunk of software. When I worked with Salesforce, we were doing a custom implementation for a client who had a lot of specific requirements that were not immediately met by the out-of-the-box solution. The Agile approach was to break each specific element of the software into a user story with its own requirements and functionality. Each user story was assigned a velocity to determine how quickly it was to be accomplished, with all of the various user stories in the sprint forming part of a larger picture called an Epic. The software used for keeping track of this was Rally, one of the better Agile tools out there.

At Caterpillar, we were building a portal for the various dealers to manage their machines, parts inventories, repair orders, and so forth. There was also a need for the dealers to keep track of their customers. All this was built on the IBM Websphere Portal, a java-based platform of immeasurable complexity that has been the backbone of many American enterprises for years. The product owner and scrum master were based in the US, while the development teams were all located overseas. The tool used for keeping track of all this was Pivotal Tracker, another good Agile organizer.

So where did UX fall in with this? In neither case was it baked into the process, mostly because there was inadequate understanding of the role of UX in the process. A proper User Experience methodology relies on a lot of research up front as well as plenty of validation and testing throughout the process. The ideal is to not waste time designing and building things that don’t work for what the customer wants to do. This is vastly different than building functional software, which only needs to be able to perform the tasks it was designed for to be judged a success. I think of it like this: Agile is all about building working software quickly, and UX is about quickly determining what software will work.

In the case of Caterpillar, there was really no way to do any pure UX other than to observe the dealers wherever possible and ask them questions about the sort of things they did day to day. In this, I was able to help prioritize what the portal needed to do in context (for example, it was important that the rental portal have a mobile component that would allow the dealer to visibly inspect equipment and take pictures as necessary.) Largely, the job became more about applying UI best practices to a complicated interface.

In the case of Salesforce, a lot of the UX research was done up front and throughout the sprints. Development and UX were done in tandem with lots of field studies and specific task and journey mapping that allowed the users to access what they needed in the context and time frame most useful to them.

The biggest takeaway from my experience is that UX needs to be at least one sprint ahead at all times, and more if it’s possible. It also helps if UX is brought in from the onset of the project with a clearly established role and timelines.

During a recent Nielsen Norman Group training, I came across a great case study that I present here as an example of how UX and Agile can be integrated effectively throughout the project:

Doing UX in an Agile World: Case Study Findings

by HOA LORANGER on May 26, 2014

Agile development processes are popular among programmers, and for several years we have studied how to best integrate Agile methods and user experience methods to create great products that don’t abandon usability while chasing after speedy programming. Our earlier research considered the broad perspective, so we now dive into a smaller number of projects to collect deeper insights for our new course on Lean UX and Agile.

I recently interviewed eight professionals who work in Agile environments to learn about their journey, their successes and failures. I spoke with people ranging from User Experience (UX) designers to developers and product owners. All worked in an Agile environment for at least two years.

Agile Is Here to Stay

There is no going back. Everyone that I spoke with admitted that the process is not always smooth, but today it is much better than when they first started several years ago. Even at the 2-year mark, some people confessed that it’s not all roses, but it’s much better than it was before—no one wanted to revert to a traditional development process such as the waterfall.

In general, Agile teams agree that this framework facilitates transparency. Issues are identified sooner and features are delivered faster. Gone are the days when developers and designers spent months and months cranking away, working independently, and only identified issues at the end. Agile has minimized last-minute surprises and allowed developers to predict timelines more efficiently.

“We are working smarter. No more 14 hour days for an entire month. We are a team and we are releasing more often… Since we’re working with smaller chunks that are not monolithic, it is easier to predict than something that is huge and can take 9 months. Everyone is aware of progress sooner.” Victor, Software Engineer

“Before Agile it was harder to stay on track. There is more accountability now. Things are more transparent.” Anca, Software Engineer

Practice Makes Perfect

After a few years of trial and error, Agile teams are getting the hang of it. People are better at timeboxing or setting time limits on activities. Daily standup meetings that used to go on for 30 minutes or more are now getting closer to 15 minutes. Team members are better at being concise and sticking to the agenda. There is a greater understanding and appreciation for the “rules” and how the process benefits releases.

Time estimates are more accurate. In the early days, some teams took on more than they could handle insprints (or units of time), but today this is less of an issue because they have learned what is reasonable work for a given sprint.

“The awkwardness is wearing off. People had to get used to the funny way of calling things and the new activities.” Michelle, UI Designer

Communication Is Key

For some team members, the biggest benefit to using Agile is communication. The Scrum method provides the structure for cross-functional team members to contribute ideas, share responsibilities, and refine the process together.

“The biggest advantage to Agile is retrospectives. It allows people to air dirty laundry, improve, and try different things… At first I was very focused on following the rules. After working in different Scrum teams, I’ve learned that I have to work for those teams… Now we have a shared vocabulary, a shared understanding.” Jeff, Product Manager

“The value of scrum is conversation. Don’t beat yourself up over following all the rules. We do as much as we can.” Cathy, Product Owner

Agile Challenges Within Organizations

For many people the Agile road is still bumpy. Gaining company-wide support has been an uphill battle. Teams must work hard to show nonbelievers the value of Agile and encourage them to break out of their comfort zones.

Lack of Executive Support

One of the major challenges with Agile is getting support from the top. Some of the people I spoke with expressed their frustration with the lack of engagement with management. Without executive backing, teams are forced to cut corners and work less effectively. Misunderstandings about the Agile process result in communication breakdown and incoherent planning.

“Requests from stakeholders that are outside of Agile mess with sprint planning.” Julia, UX Designer

“We’ve had to work on stuff that is not part of planning.” Cathy, Product Owner

“Our group is embracing Agile, but our organization is not there yet. We’ve had a couple of Agile coaches, but the coaches were not great at swaying senior management. They didn’t have an impact to get senior management onboard.” Mandy, Senior Programmer Analyst

Inadequate Resources

The lack of executive support usually results in diminished resources. The practitioners I talked to agree on the merit of Agile and Lean methodologies such as Scrum. Each Scrum component is structured to address a process need. Some of the most successful projects occur when teams can commit to the methodology. However, almost everyone I interviewed didn’t follow the recipe or was forced to take shortcuts. The main reason: lack of resources.

Absence of User Research and Usability Testing

Our Agile panelists agree on the importance of validating designs. Unfortunately, most teams don’t conduct user research on a consistent basis, if at all. People cite tight deadlines and staffing shortages as reasons for deficiencies in user-centered activities. However, discount usability methods can accommodate short timelines as needed.

Skipping user research is extremely risky. Even the best design ideas are just assumptions. There are limits to a genius designer. User research allows us to test our assumptions and prevents cognitive bias from taking over and leading us astray.

“We work under internally imposed deadlines and sometimes need to push things out without testing, which is suboptimal for users.” Julia, UX Designer

“It’s really hard to make usability testing happen. We are short-staffed and don’t have a primary researcher. We’ve borrowed someone from marketing, but he doesn’t know the product enough or abide by our philosophy of ‘we love our users’.” Julia, UX Designer

“We don’t have time to run user testing.” Victor, Software Engineer

The good news is Lean UX techniques such as sketching, wireframing, and paper prototyping have gained support. Designers are encouraged to create low-fidelity prototypes as a way to demonstrate ideas and reduce heavy documentation. The downside is that many organizations are not testing them with target users.

“We try to be somewhat lean. My boss is encouraging us to not use wireframes—go with sketches. It was a difficult transition. People joke of me being a wireframing addict. Sketches helped me understand the idea of what we are all thinking.” Julia, UX Designer

“We’ve been doing quick and dirty paper and drawing mockups and collaborating with development more.” Mandy, Senior Programmer Analyst

Tips for Running Smooth UX Agile Teams

Keep Teams Consistent

It takes time to build a good, cohesive team with the domain knowledge to make the right decisions quickly. Each Agile team may work differently and have a unique team dynamic. Disrupting the system wildly interrupts velocity because knowledge and expectations must be reestablished.

“Team consistency is key. Stop reorganizing and shuffling people around. Teams that stay together, learn together, and keep getting better and faster.” Derek, Lead Researcher & UX Designer

“It’s a challenge for me because resources are not dedicated. One week we have this person; next week we have another person. We got an Agile coach onsite but if everyone doesn’t get the training or stick to a project long enough, then you have to start over again when you get a new person… Don’t move people back and forth between Agile and waterfall.” Michelle, UI Designer

Be Proactive Not Reactive

If you are used to working “head down” for long stretches of time, then you need to change your work style or risk being outdated. Collaboration is key in successful product development. The involvement of cross-functional team members facilitates transparency and allows issues to be identified early. Be involved in all aspects of the design process, including planning. Be prepared to share your ideas, show what you are working on, and contribute to discussions.

“Everyone needs to be proactive in improving communication. Be invested in your team and what you are creating. Be an owner not a renter.” Julia, UX Designer

“Developers need to ask, not just take orders. Everyone needs to be interested in working as a team.” Julia, UX Designer

Have a Dedicated Scrum Master, Especially at the Beginning

If you are thinking about going Agile or you are just starting out, make sure to allocate budget for a Scrum master. This person will ensure that the process goes smoothly. Without an experienced coordinator, there is a good chance that things will go wrong, leaving people feeling disgruntled about the process.

“Make sure you have a dedicated Scrum master. If you can’t do that, be clear about roles.” Mandy, Senior Programmer Analyst

“The Scrum master is a sheep dog, bulldozer, and coach. They make sure issues get resolved and the team is motivated. The danger of not having a Scrum master is that everyone thinks the process is disorganized.” Jeff, Product Owner

UX Must Work at Least One Step Ahead of the Sprint

Agile is development friendly, but that’s no excuse for reducing UX’s influence. Effective UX professionals incorporate themselves in the Agile process by actively contributing ideas—from backlog grooming and print planning to wireframing and user research. UX designers must plan activities before the sprint occurs, which means being proactive and testing assumptions and tackling designs ahead of the rest of the team. They conduct “show-and-tell” activities ahead of sprints to introduce concepts to users and team members so that, when development is ready to begin, the team has the designs that they need.

“The UX designer must be at least one step ahead of the sprint. In other words, do research and design work outside of the current sprint. I have to keep laying the tracks for the team.” Derek, Lead Researcher & UX Designer

“The UX person should go ahead of the sprint with mockups.” Michelle, UI Designer

“Design a little ahead of development. Development is more comfortable with that. They don’t want ambiguous concepts.” Jeff, Product Owner

Conclusion

Agile will continue to gain momentum as organizations discover the benefits. UX professionals must adapt to Agile and lean UX processes, which value transparency, collaboration, and responsiveness or risk being left behind.

The Agile user-experience process is more than just being a thoughtful designer; you must first know the user and continually test your assumptions. Don’t allow user research to run away from you during the compressed timeline of the Agile process. Get out of the office and learn from your users. It is possible to incorporate lean UX techniques into an Agile development process. Methods like online user testing can get you user feedback in minutes.

UX Pros Never Sleep

Leave a reply

I found this blog from UX professional Jennifer Aldrich, a UX maven working at InVision and other places. Wherever I am, I am aware of the experience. It’s the same way I am aware of music production, film editing, writing, the way people walk and gesture, accents and a bunch of other things. This is because I play drums and record music, make short films, write books and screenplays, cartoon and animate. I take a professional interest in how things are done to see if I can replicate them and maybe do them better. UX is no exception. Don’t get me wrong– I dig the slick UI tools that are out there. Lately I’ve been going nuts with Sketch and Flinto making bouncing snapping mobile interfaces, and I’m looking into a couple other great new tools that code as well as give you GUI controllers(I’ll post my thoughts sometime soon). But UI is just UI unless it’s underpinned by a deep understanding of the user in context. As a designer, I need to understand who a person is, what they want, and how they usually do things. I need to know what else they use and what their expectations are. The key to all this is observation and attention.

Besides, in this world of continuous and continual micro-distraction, it’s an excellent discipline.

Here’s Ms. Aldrich’s piece:

UX PROS: ALWAYS ON THE JOB

20140509-160550.jpg

I used to think it was just me, but it turns out tons of UX pros suffer from the same affliction: we can’t help mentally redesigning everything around us. And you know what? It’s not really an affliction, it’s a gift. It’s what makes us awesome at our jobs. We see the world in a completely different way. We view the world with the mentality that everything around us can be improved, and we are able to visualize those phantom improvements. We want to fix all of the things. It’s actually pretty awesome when you think about it. We see what no one else can see: the potential for a better world.

I was on vacation with my daughter when I walked into the hotel bathroom and exclaimed, “This shower head design is horrible!” My daughter called from the other room without missing a beat, “Mom, we’re on vacation, stop analyzing the usability of the bathroom fixtures so we can go to the pool.”

Seriously though, worst shower head design ever. I took pictures to prove it. haha

20140620-154551-56751520.jpg

So the next time you’re sitting in a restaurant explaining to your significant other why the font choices for the menu are terrible, or staring in disgust at the kerning in your child’s holiday play flyer, or you’re explaining to a miscellaneous stranger at the bus stop why the bench should be turned at a 45 degree angle so that passersby won’t bang their kneecaps on it; know that you’re not alone. There are many others who, like you, can’t help wanting to make the world around them a better place, one experience at a time.

Superimposed Experience

Leave a reply

20150527-moorhead-dq-cone-5-jackie-varriano

 

I’m writing this post is response to a prompt I found on the Toptal Freelance Interactive Designers Group website. They ask me to talk in a general way about I want to bring to UX. In short, it’s one of my goals to stamp out bad UX everywhere I find. My goal is to increase empathy and help people solve problems through better design.  Bad UX is not limited to terrible apps and crummy websites. It exists everywhere. Take this, for example:

Last Tuesday I got back from a trip to Seattle (where I was attending the Nielsen Norman Group UX training, which I may cover in another post) and we decided to celebrate by going out for burgers. We went the Starlite, a no-frills burger place that’s been run by the same family since the 1950s. The burgers are huge and inexpensive, taste great and are always the same. They arrive wrapped in customary white waxed paper and are served ála carte, fries and onion rings sold separately. It’s an absolutely consistent experience, and as a result the place is packed every night.

In the same parking lot is a Dairy Queen of about the same vintage. The establishment complies with the franchise’s expectations. Blizzards are served upside down or the next one is free, etc. They do a good business despite the fact that Cedar Rapids has a disproportionate amount of Dairy Queens for a city its size. I think we have about one per square mile, but I might be mistaken.

And as it always has been at Dairy Queen, the staff is comprised exclusively of teenagers, which brings me to my point.

Last night after our grease-fest of a dinner we walked across the lot to the DQ and got ice cream. My wife and I, both full as ticks in summertime, each ordered a small dipped cone. We were served gleaming towers of candy-coated soft serve, ten ounces at least, bulging over the sides of the cone like John Goodman in a t-shirt.

It was way more than we wanted or needed; we ordered smalls because we wanted smalls.

Why were the cones so big? I have a theory, and (as always with me) it is a UX theory. See, the guy who served us was a teenager. In his world. the only possible reason you would get a small cone is that you can’t afford a big one. He thought he was doing us a favor, even winking at me as he handed the teetering confections through the service window. “Here are your smalls, sir.”

You see, he superimposed his experience on ours. His world was all he thought about as he piled a pound or so of ice cream onto the tiny cones. With every good intention he harmed the business (infinitesimally) by wasting product and, especially, by not giving us what we wanted.

Of course, I didn’t call the manager and threaten them with legal action, nor did I organize a group of picketers to yell obscenities at their customers. In fact, I dutifully ate the entire cone, but I regretted it. I don’t need any help gaining weight these days. Will I be back to Dairy Queen? Will I be back to that Dairy Queen? Probably. This isn’t an actual problem, only a hypothetical.

This is the conundrum in design: we start by designing for ourselves, creating something that pleases us. How many times as I designer did I sit in meetings with a client only to watch them choose the comp I threw in at the last moment instead of the one I toiled over? Countless. But at a certain point, I came to the tremendous realization that I was often wrong. What I like is not necessarily what the user will like. This is why UX research is so important. In order to design from the outside in, I need to understand the user and what they are trying to do. If you add mobile into the sauce, I also need to know where they are trying to do it.

Southern_Vectis_311_HW54_BUO_and_Ryde_Tesco_bus_stop

For example, a public transit website could benefit greatly by having its mobile version prioritize the top question one might have while at a bus stop:
-When is the bus getting here?
-When will it arrive at the destination?
-How do I get a bus pass?

And so forth. This added dimension of empathy can lead to some surprising solutions, especially if a top-notch developer is roped into the prototyping process.

The best thing about the global campaign to eliminate bad UX is the amazing opportunities that you come across in day-to-day life.

The Canadians Who Really Invented GUI

Leave a reply

This article borrows heavily from Clive Akass, who wrote about this in 2001. It just goes to show you that people will reject a forward-thinking idea because of things that have nothing to do with its merits.

DATAR-Trackball

Everyone knows that Steve Jobs and Steve Wozniac started flogging Apple 1 circuit boards from a Palo Alto garage until 1984, when the first Apple Mac made its appearance, with its revolutionary mouse-driven graphical user interface (GUI).

Apple’s achievement in recognizing the potential of the GUI and putting it into a mass-market machine cannot be denied. But Apple did not invent the system, as many still believe.

The basic elements of both the MacOS and Windows were developed at Xerox’s Palo Alto Research Centre. Xerox did not patent them and blithely showed them off to Jobs, who promptly snaffled the lot.

The roots of the system go back still further. Every computer history website will tell you that Doug Englebart, hired by the US Defense Department to find new ways of harnessing the computer, invented the mouse in 1963.

But this is true only up to a point. Englebart’s contribution was important, but his ideas didn’t come out of the blue.

Roots in radar

Like the pulse circuits that provide the heartbeat of computing, the GUI has its roots in early radar systems. It was wartime radar work that got Englebart thinking about dynamic information displays, and radar engineers were the first to encounter the problem of how to use these displays to communicate with an intelligent machine.

Two engineers came up with a trackball, the innards of the mouse, a full 11 years before Englebart unveiled his device. Moreover, it was used to select a position on a screen to convey information to a processor, which is the fundamental operation of a GUI. One of the engineers, 80-year-old Tom Cranston, is still alive and living in Scotland.

Cranston’s early career nicely mirrors the shift the electronics industry went through in the 1940s and 1950s. Pre-war electronics was overwhelmingly analog, using thermionic valves as amplifiers, oscillators and detectors.

Cranston, who was born in Canada, spent World War II in Britain maintaining Air Force analog radio equipment.

After the war he took an electronics-focused engineering physics degree at the University of Toronto, before joining Ferranti Canada at a time when it was trying to gain a foothold in the nascent computer industry.

This used valves predominantly in switch mode for logic circuits. “What I studied in electronic circuits at university had nothing to do with what was set before us at Ferranti,” he said.

The Datar system – starting from scratch

Cranston was project engineer with a team working on a system for the Canadian Navy called Datar, an attempt to marry radar to digital computers which was way ahead of its time when it started in 1949.

Datar enabled a group of ships to share sonar and radar information. Up to 500 objects could be identified and tracked, and each ship saw the whole position plotted relative to its own moving position.

These calculations would be trivial today, but for Datar the logic had to be hard-wired using around 10,000 valves per ship.

Everything had to be done from scratch. The young engineers recruited for the project even had to prove that data could be transmitted by radio – a demonstration (using pulse-code modulation) that finally persuaded the cash-strapped Canadian government to back the scheme. Positional information was stored on a magnetic drum, a precursor of the hard disk.

The demonstration system on Lake Ontario used standard radar displays with a rotating beam that showed the blips of nearby aircraft, and ships; sonar data from notional submarines was simulated. They needed a way for an operator to identify a target blip and to enter its position.

These displays were drawn by conventional analog circuitry: there was no video RAM to play with. An electronic dot cursor could be thrown up during a brief flyback period between screen sweeps; the engineers needed to find a way that the operator could position this cursor smoothly over a target blip and store the co-ordinates.

To Cranston and his colleague Fred Longstaff, this was just another problem to be solved. “It didn’t seem a big thing… there was a tremendous urgency about all this and it is hard to recreate that atmosphere.”

The simplest answer would have been to set the dot’s X and Y deflections separately using two variable resistances, as used in nearly all electronic level controls, and then translate these values into digital co-ordinates.

Cranston and Longstaff came up with a far more elegant solution that used one control instead of two, and delivered the co-ordinates directly.

The wheel thing

Cranston, while on a visit to a naval establishment, had seen someone using a wheel on a stick, like a miniature pedometer, to measure distances on a chart. “We need something like that which works simultaneously in two dimensions,” he said to Longstaff.

Longstaff then came up with the idea of two follower wheels resting at right angles to a ball that was free to roll in any direction. The prototype actually used two pairs of wheels driven by a standard 4in Canadian bowling ball resting on an air bearing, a feature that is simpler to make than it sounds.

“You just mix up some plaster and stick a ball in it when it is beginning to set,” explained Cranston. “Then you let the plaster harden, take the ball out, drill holes into the plaster, and pump air through them. The result is like magic.”

A circle of holes close to the rim of each wheel passed a beam of light to a photo-sensor, which produced a string of countable pulses as the wheel rotated. Counting circuits were well understood by then, Cranston recalls.

One wheel measured upward movement and its opposite registered down, and the count was incremented or decremented accordingly to provide the Y co-ordinate; the other pair worked similarly to get the X co-ordinate.

Shutters blocked light from the two wheels’ measuring movements opposite to the current rotation. A button – the equivalent of a mouse click – was pressed to indicate a target.

Now and then

Through today’s eyes, this arrangement seems over-elaborate: why not use two wheels and a direction flag? Half a century later, Cranston cannot recall the details of why it was done in this way, but it seems to have been a matter of using what was at hand. Nowadays, a single line of code could cope with the changing directions; the Datar team had to hard-wire everything.

Also routine now is the control of screen positions by numbers, but it was new and intriguing to Cranston and Longstaff. An analog control would have a unique position for each screen co-ordinate, but there was no such direct relationship in the case of the trackball: if you moved the cursor by altering the stored number, the ball would still work regardless of its orientation.

They thought of the device as “centreless” and Longstaff jokingly referred to it as the “turbo-encabulator”.

The whole exercise was what in today’s jargon would be called a proof of concept. The team had to show Datar could work in order to raise the money to refine it, and it needed a lot of money. Valves were unreliable and not really suitable for use on a ship, so the whole system would eventually need rebuilding round new-fangled transistors.

Canada could not afford to do this itself and was seeking a partnership with another country. A system was demonstrated to a succession of military and technical decision makers. One US military observer was so astonished by the sophisticated display that he peered under a table to ensure there was no tomfoolery going on.

Nobody bought into the system. Britain and the US, the most likely partners, had their own projects and there was probably a “not invented here” factor.

Ironically, a prototype US system that Cranston saw later at MIT didn’t need a trackball because it was more advanced: targets were identified and tracked automatically.

Research unrewarded

Many people, though, had seen the trackball. The question of patenting it never arose. Ferranti UK, the parent company, had limited contact with its Canadian arm. Executives had little idea of what was going on at the research level.

Cranston said: “Think about the state of play in the computer world in 1952. There were only a handful of operating computers in the world. Almost all were unreliable. There was no common software language… pulse rates were only 50-100kHz. The idea of using a ball to control a cursor which could intervene and change program execution was a million miles ahead.”

Ball resolvers were not new. They had appeared in navigational and ballistic control mechanisms. The achievement of Longstaff and Cranston was to see how one could be used in conjunction with an electronic display. It was, Cranston says, a generation before its time.

Where Datar went

The Datar experience went into a programmable computer called the FP-6000 which was launched in 1961 by Ferranti Packard – the original company merged in 1958 with Packard Electric.

The FP-6000 was one of the first to use an operating system and was ahead of IBM rivals in its ability to multi-task. Its chief architect was Longstaff. He ended his career as a comms guru with Motorola and died five years ago.

The FP-6000 ended up with ICL, after being bought by Britain’s International Computers and Tabulators, and the two UK firms sold 3000 of them worldwide as the 1900 series.

Cranston left Ferranti in 1956 to take what he describes as a “giant leap backwards”. He joined the Canadian arm of a US company making data loggers and alarm scanners for the Canadian power industry that used logic in the form of mechanical switch arrays.

Electronic computers were considered too unreliable and too expensive for the task. Telephone relay logic filled the gap for another decade.

In fact, Intel’s seminal 4004 was designed originally for tasks like this.

Cranston left after 11 years and moved near to Inverness with his Scottish wife, setting up home in an old mill that he converted himself. He taught for several years in the local technical college, introducing students to the mysteries of the microprocessor.

Surprisingly, Cranston does not have a computer. “They are too fascinating,” he said. “I’d get so involved, I wouldn’t have time for anything else.”

Wireframes and Personas

4 Replies
Image: Gayatri S

Image: Gayatri S

These past few months I have had the opportunity to do freelance work with a few different agencies and have had wildly different experiences. One thing that becomes clear is that, while UX is a buzzword and many clients seem to want it, many agency heads (account executives) don’t really understand what it is. And now the buzzword has changed again: “Lean UX.” This makes it more complicated, because UX itself is so poorly understood that adding a modification complicates communication all the more. I’ll attempt here to clarify a bit.

“You do wireframes, right? Because our clients expect wireframes.”

One of the main obstacles facing many agencies incorporating UX into their process is the idea that design deliverables are the only evidence of billable time. I can’t tell you how many times I’ve been on a team of designers who worked hard to making an initial iteration of a comp pixel perfect; it’s the industry standard and clients rightfully expect it, especially with deliverables destined for print. When we apply this expectation to web work it makes less sense (browser and device differences being among the chief factors), and when applied to UX tools such as wireframes it makes none whatsoever. Since UX has popped onto the client radar, the expectation is that wireframes comply to the same exacting strictures as design deliverables.

This somewhat defeats the point of using wireframes at all, since if one is going to wireframe in Illustrator or Fireworks then one may as well be designing instead. Clients see these documents and focus on visual specifics rather than functionality. This also holds true to a lesser degree for personas and taskmaps, other crucial tools for a user experience designer. This is not to say that aesthetics are not a very important part of UX; they are, but they don’t apply to wireframes.

Wireframes function as a point of reference that will allow quick collaboration between the business strategist, the interaction designer, the developer and the graphic designer. they can come in different flavors from napkin sketches to fully interactive simulated sites. The idea is that you can test the way the interaction actually functions.

 

The great thing about using a tool such as Axure is that you can do a pretty good of showing how the site will actually function and be able to demonstrate and test it… all without needing to involve your development team. A wireframe interface  is easily modifiable, too. If something doesn’t work, it is easy to change it.

So what exactly ARE we delivering?

My experience has shown me that user experience design benefits from using a programmer’s mentality of asking first what it is we’re trying to do. As a UX designer, my questions are simple:

1. Who is the user and what are her priorities?
2. What does the user want when she uses this tool, website, or app?
3. What does the business want her to do?
4. What is the best way to address of these needs simultaneously?

 

Where do personas fit into this?

Right at the beginning, because personas are the tool that we use to keep us on track. But what are they?

First, what they’re not:

Personas are not a demographic. They aren’t  a segment or a group, though that’s where they start.  Really, a  persona is a fictional, yet accurate, depiction of an actual user. The goal of a persona is to humanize the target audience so we can better understand their motivations and behaviors and how they will interact with the interface. We need to know who these people are and what they want.

In reality, personas should be the locus of the entire development process because they ensure that we are designing for the user, not themselves. Personas will create alignment on this key point.

That’s all well and good, but how do we know? Often, businesses think they know their customer through and through. Often, they are wrong. They forget the all-important fact that they are not their customer.

Ideally, the process of creating personas typically begins with baseline demographic information that provides known demographic data with quantitative insights to identify core similarities and differences. This will divide the audience into segments.

Then, that information is sifted further by using third-party research tools to start identifying individual characteristics based on demographic and other factors.

Once the differentiating factors between the various individuals are fully identified, we are in the position to form some hypotheses about  our users. We might find that certain of them only interact with the site at night and draw some conclusions from that. These conclusions need to be confirmed of dis-proven by actually talking to real users. This can be done with surveys, emails or face-to-face interviews.

The final validation is achieved by conducting more extensive interviews with subjects who closely match the personas. Such individuals can also be used for user tests on existing interfaces for the purposes of auditing websites and competitor analysis as it affects the core of the target market.

The end result is typically three to five individual personas that I humanize. Each persona contains a name and picture along with an extensive background (including city, job title & salary, marital status, age, race, family, etc.), prime motivators, expectations, buying patterns, technology patterns, pain points, favorite brands…in short, a well- rounded look into the specific factors that may come into play when the user engages the product.

Realistically, this can’t always happen. In fact, I’d go so far as to say that only a tiny portion of personas are grounded in the kind of research that’s really required. It’s expensive and time-consuming and usually the client doesn’t want to spend for it because they believe that the research is enough.

It’s not, for one key reason:

Research is not a design tool. Personas are, and by using them in every case we ensure that we are not designing for ourselves. 

So what’s usually done are proto-personas.  These start with some quantitative research by marketing firms such as Forrester and are essentially fleshed-out versions of the demographic. In-house subject matter experts and business owners can help confirm hypotheses and help personalize the personas. I have found LinkedIn and my own personal network to be a great use in confirming a hypothesis that is shown in the big-picture research. Quick emails to people I know who match the target can help, as can a phone or face-to-face conversation. Most recently I was working on personas for a pool table manufacturer and talked about the tables with my barber, a pool enthusiast. There are ways to do that don’t involve the sticker shock of full-on process.

And getting 80% of the way there is a lot better than having nothing, or worse: a bunch of wholly fabricated stuff.

 

 

When User Interfaces Fail

Leave a reply

I came across this today, and rather than paraphrase or link to it I thought I’d just paste it in (credit and link included.) This was done in 2004, the stone age of UX. I recall trying to convince huge companies that user experience went far beyond usability and was absolutely necessary. Unfortunately, these entreaties fell on deaf ears since the then-largest company in the world didn’t give a hoot about usability. And where is Microsoft now? Apple proved it… UX and CX can turn the fate of a company around. Facebook, which differed from MySpace in its interface inflexibility (no custom pages, whereas MySpace had all sorts of customization options), triumphed with its emphasis on functionality and immediacy. Any thoughts?

Some people like to do “designer bashing” from time to time. I was just in the mood to do some “developer bashing” today.There are a number of reasons why user interfaces of many software packages fail. I assume (slightly unfair and inaccurate), that in many cases there is no interface designer involved with user interface development, but rather the interface is designed by the application developers.

 

 

 

 

 

Here is a list of (some) common fallacies of some developers in regard to user interface design:

Fallacy #1: User centered design approach is optional.

Some developers actually have no idea what “user centered” actually means (as many consider the implementation of software that users can interact with already as being “user centered”). Also, the most important aspect of user centrism to developers is the feature list, because the features describe what the user could do. The actual ability is a function of a) the features and b) the capability of the user. What is not agreed on many times is that “capability” is not solely an attribute of the user, but is constituted by user experience level plus interface design. The 80/20 rule is applied as 80% application development and 20% interface development instead of the other way around (and in the order “first interface then application”).

Fallacy #2: Features are more important than usability.

For some developers the loss of features during planning phase seems to be a too big tradeoff in comparison to a “minimal” usability improvement.

Fallacy #3: “Design” is just an emotional and subjective quality.

Some developers think a “design” will just become necessary if the application should not only work, but also please and delight. While “likeability” is an important aspect, it is heavily underestimated how much users dislike software that is hard to use.

Fallacy #4: Functionality is what the user could do.

Some developers consider “functionality” being an aspect of the software. In fact “functionality” is an attribute only present in the usage context – where the user is the most important variable. Functionality is not what the software provides, but what the user is able to use. Microsoft Word may have many thousand functions which most users are unable to use. So the functionality of MS Word for users is what they can actually (and not potentially) achieve.

Fallacy #5: Personal experience is the best advisor.

Some developers often think they are able to do “cognitive walkthroughs” on behalf of unexperienced users. While this is a possible approach, many developers (that usually are power users with deep knowledge about the application) do not go far enough when defining “unexperienced”. When doing cognitive walkthroughs many developers keep the same mindset about what is important inside the application. Really unexperienced may consider completely different things as being important.

Fallacy #6: Good application design is the primary determinator for good interface design.

Most developers are interested in designing the application (that’s why they call themselves “developers”). Interface design is an uncomfortable requirement to be added to the application design. While there is much truth in the idea, that well designed applications often offer cleaner approaches to interface design, it is a false conclusion, that a well designed application will necessarily lead to a good user interface.

Fallacy #7: It’s OK to reject major changes of the application for minimal interface design improvements.

Well, sort of. Most of the time it is basically a matter of a wrong design approach in the first place. There is also a persistent understanding of developers that interface design issues do not interfere with the deeper application design – which is simply ignoring the fact that in most cases it remains to be the case.

Fallacy #8: A bad user interface alone cannot set the seal on the fate of the application.

It seems to be irrational to developers to prefer going with no software and unresolved problems instead of trying to work with a hard-to-use application. Unresolved problems can often be deferred or ignored – or – other workarounds could be tried with an easier path to a less optimal solution.

Synergy with Analytics and Marketing

Leave a reply

As I have said in an earlier post, analytics should be a powerful component of your overall marketing strategy from the start. Properly used, they can show you how your customers are reacting to your efforts to attract them. This is great information for a whole host of reasons, not the least of which is to know when you’re barking up the wrong tree.

Nothing feels quite as bad as having to justify a loss incurred by an unsuccessful campaign, particularly if you had tools at your disposal that could have warned you of its ineffectiveness before you were completely committed.

Analytics, therefore, should be factored into online and offline marketing efforts from the very start. To properly set up analytics, though, you need to know the places where they can be of most use. Initially, there are three main areas where they can help:

1.      Keywords

For the uninitiated, keywords are the search words with which users find your site. The right keywords will drive the right traffic to your site  ultimately help both your customers and you by giving site visitors what they want and need.

Analytics provide you with insight into which keywords are effective and which keywords are not. A word or phrase that you believe accurately describes your product may not be  the one used by your customers.  Searches can also be affected by context in which the keyword is used. This is especially true now that Google has implemented Penguin, an artificial intelligence-based system that goes a long way toward assessing websites’ value in the same way as real life customers. (I will address Penguin and its impact for SEO in a later column.)

So which keywords are the best for your site? You can use analytics to easily determine this by checking

  1. Which keywords drive traffic to your site
  2. Which keywords drive conversions
  3. Which keywords drive traffic but no conversions

Determining the difference between numbers one and three will give you the answers you need and will  help you adjust your course.  Check the following:

  1. Does the keyword describe your product?
  2. Is the keyword too broad?
  3. Does your site offer quality content around the keyword?

Keywords can drive traffic but not conversions for a myriad of reasons. For example, say you offer websites and a company doing initial competitive research for a new business searches for “startup business websites”  and comes to your site. If your those are your keywords, the user will come to your site more or less by accident and leave without doing anything. The proper content in the description would allow the user to determine a more appropriate site for their needs,

 

Landing Page Content

One of the greatest assets of any analytics software is the ability to break down your website page by page.  You can see how many people landed on a page, how many people exited a page, where they came from, what keyword they searched to get there, how long they spent on a page and most importantly, you can see if they converted.

By breaking down the top landing pages, you can determine just how customers interact with your website and how with the right design and content, you can give them a great experience.

When thinking about your landing pages, consider the following:

  • What are the top landing pages?
  • Which pages have the highest bounce rate?
  • What pages do people spend the most time on?
  • Which pages lead to the most conversions?

Your home page (index.html)  is usually the top landing page; it typically will also have the highest bounce rate because a bigger net catches more fish, but not all of them are the right kind. The home page is also the most indexed by search engines, literally the front door of your website through which every guest passes. If your home page does not have direct calls to action or clear paths to valuable information, users will go elsewhere.

This is where specific landing pages come in. It is very common to create landing pages that contain less general information and more specific direct calls to action. They can also be linked directly to PPC ads and specific search strings.

Using analytics for your landing pages you can easily determine why they are successful.  What keywords did visitors use to get there?  What type of content is on that page?  What calls to action are you using?  Can this be replicated on other pages?

Remember, determining customer behavior on your site  is just as important as knowing what search terms brought them there.

Buying Cycle

How long is the buying cycle for your product or service?  How many times does a customer visit your site before buying?  What are they looking at during that time?  With an online business and website analytics, this information is not just available, it’s invaluable.

To begin, answer the following questions:

  • How many days after the first visit do people convert?
  • Which pages do they visit during that time?
  • What content do the pages contain?
  • What calls to action are you using?

By knowing where your customers are in the buying cycle, you can really refine your online marketing efforts (this is especially true when it comes to paid search). If you know a typical customer comes to your site and reads 5-7 information-based pages before they convert, you can gear your initial messaging and calls to action around that. Instead of saying “Buy now” you can say “Get more information.”

For paid search campaigns, determine which keywords correspond to which point on the buying cycle and drive users to landing pages with the content they need at that point in the process.  Using the same example we used in the “Keywords” section, drive the person searching “business websites” to a page that provides ideas on creating a business website.

As always, a usable, informative website that has the customer needs will be revisited when they do decide to buy.

So a guy walks into an office and offers UX services…

Leave a reply

Doing a first-time UX consultation, I sometimes feel like an auto mechanic walking into a buggy shop circa 1905 and trying to tell the carriage maker that the horses will soon be outclassed. It’s hard to consult from a defensive position, even when the writing is on the wall that things are changing. The main issue is that the service I offer is often seen as either redundant to current efforts or entirely unnecessary… or even nonexistent.

Even with the prevalence of social media in our culture and the fact that customers are becoming extraordinarily sophisticated in their methods and ability to access online media, there still remains a level of disconnect. The old methodologies of dealing with customers is amazingly stuck in the past. It is often driven by the marketing department and utilizes communications techniques used in traditional advertising. The message is broadcast, the results are monitored and changes are made to correct any missed opportunities. Analytics suites and lead tracking software have added useful tools to find and collate information,  but the the overall method itself hasn’t changed in its basic philosophy. One thing that has changed is the speed with which a customer or user can change direction: one click and they are gone, usually for good.

This isn’t because businesses don’t want to change. The technology is everywhere… most people carry a computer in their pocket that is much  more powerful than the most expensive desktop machines of ten years ago. The relationship businesses hope to have with customers through these new devices is clear, but the method being used is, at its root, one-sided.

Brian Solis of Fast Company Magazine wrote in a recent article :

“Rather than examine the role new technologies and platforms can play in improving customer relationships and experiences, many businesses invest in “attendance” strategies where a brand is present in both trendy and established channels, but not defining meaningful experiences or outcomes. Simply stated, businesses are underestimating the significance of customer experiences.

…As smart and connected technology matures beyond a luxury into everyday commodities, consumer expectations only inflate. As a result, functionality, connectedness, and experiences emerge as the lures for attention. For brands to compete for attention now takes something greater than mere presences in the right channels or support for the most popular devices. User experience (UX) is now becoming a critical point in customer engagement in order to compete for attention now and in the future. For without thoughtful UX, consumers meander without direction, reward, or utility. And their attention, and ultimately loyalty, follows. “

It comes back to the simple questions that businesses need to be asking:

  • Who are your customers?
  • Why do they like you?
  • How do they buy from you?

One problem is that marketing departments often believe they know the answers to these questions, but when pressed will admit that there is little empirical evidence to support their beliefs. Creative campaigns are often based on clever concepts, but don’t incorporate engaging experience design. Sometimes this can pay off and a campaign will be incredibly successful, but sometimes it can bomb. It need not be random because a clever idea can be paired with an engaging experience every time…  but only if  it is designed that way from the start.