Tag: design

Posted on

Teamwork reduces design risk

It takes a range of skills to develop a product. Each skill—embodied in the individuals who apply that skill—brings with it a different focus:

  • Product managers talk about features and market needs.
  • Business development  talk about revenue opportunities.
  • Developers talk about functionality.
  • Usability analysts talk about product- and user performance.
  • Interaction designers talk about the user experience.
  • QA talks about quality and defects.
  • Marketing talks about the messaging.
  • Technical communicators talk about information and assistance.
  • You may be thinking of others. (I’m sorry I’ve overlooked them.)

What brings all these together is design.

Proper design begins with information: a problem statement or brief, information about the targeted users and the context of use, the broad-brush business constraints, Design as a teamsome measurable outcomes (requirements, metrics, or goals), access to a subject-matter expert to answer questions about the domain and perhaps to present a competitor analysis.

Design continues by saturating the design space with ideas and, after the space is filled, analysing and iterating the ideas into possible solutions. The design process will raise questions, such as:

  • What is the mental model?
  • What are the use cases?
  • What is the process?

The analysis will trigger multiple rapid iterations of the possible solutions, as the possible solutions are worked toward a single design:

  • Development. What are the technical constraints? Coding costs? Effect on the stability of the existing code? Downstream maintenance costs?
  • Usability and experience. Does the design comply with heuristics? Does it comply with the standards of the company, the industry, and the platform? Does paper-prototyping predict that the designed solution is usable?
  • User experience. Will the designed solution be pleasing due to its quality, value, timeliness, efficiency, innovation, or the five other common measures of customer satisfaction?
  • Project sponsor. Is the design meeting the requirements? Is it reaching its goals or metrics?

It’s risky to expect one person—a developer, for example—to bring all these skills and answers to the table.  A team—properly facilitated and using an appropriate process—can reduce the risk and reliably produce great designs.

Posted on

Why pen+paper is better

When solving a software-design problem or a web-design problem, you get the best results from following a design process. I’m not referring to something I made up. I’m referring to something that people who are trained in “Design” will recognise as a design process. And such processes inevitably include divergence and convergence.

Divergence is the stage when the designer or design participants come up with ideas. Lots of ideas. Not just comfortable ones, but ideas that push at the edge of the envelope. Ideas without judgement.

Convergence is the stage when ideas are judged, rapidly iterated, assessed, and checked against the requirements.

In my experience, divergence is best done by sketching, with a pen on paper:

ideation-methods-on-a-graph

Sketching on paper with a wide-nib pen is best because this “technology” is familiar—it’s easy—and inexpensive. Everyone can Wide-nib markerhave a pen and paper, so there’s no need to wait your turn. Sketching is fast, so designers have little invested in any one sketch. Modifying or iterating any one of the ideas is easier to accept. Most importantly, for inexpert sketchers, the sketching process intrinsically discourages high-fidelity work and the wide-nib pen discourages sketching the fine detail that detracts design participants from getting the ideas out, fast.

Software that’s intended to help people “sketch” detracts from a good result. The software often lets users build prototypes with a great level of interaction detail. The problem with this: attention to detail is a distraction at the divergence stage. When filling the design space with ideas, it’s sufficient merely to evoke the idea and share it. Ambiguity actually helps the team see more than one idea in the same sketch; each interpretation of the idea can be iterated. Software that’s not intended to help people to “sketch” slows them down at the divergence stage—just when we need ideas to flow quickly. Divergence is about filling the design space with lots disposable ideas.

Read my blog post about why ideas are disposable.

Posted on

Design can change the culture

I was reading a comment by Creative Sage CIO and CEO, Cathryn Hrudicka, about corporations that want to use social media to reach their market:

The process of trying to become a more “transparent” organization, so they can use social media tools, pushes many organizations—companies, nonprofits, trade associations—into change, especially if they have had a very bureaucratic and non-transparent culture before. That can mean many levels of changes, which usually bring up issues between executives or managers and their teams, and it can affect relationships between staff or team members. Individuals often need to be coached to adapt to the new practices or even to drive them more effectively. Some leadership and teamwork issues come up, too.

It reminded me of a company that changed after I was asked to introduce an ideation-design method. The management team wanted the method to do double duty—a way to empower and encourage the development team.

Prior to this, it seemed team members had been discouraged from taking design initiative. Half the team was disheartened or miserable, the other half of the team was disengaged to the point where they wouldn’t offer a design suggestion even when asked by their boss. Initially, some team members took a wait-and-see approach, but after training and several successful project experiences, the majority of developers became increasingly comfortable with involvement in product design.

It took commitment from key managers to invigorate the team, and it took considerable time. They still use Five Sketches™ today.

If you liked this post, check out a recent post about Google’s corporate culture.

Posted on

Design and engineering culture

I’m sure Douglas Bowman’s blog last week was widely read. His post was a kind of public exit interview, titled Goodbye Google.

Goodbye GoogleAs Bowman left Google, he pointed out the pro-engineering bias in its approach to problem solving—including problems of design. Two of several examples he gives:

[…] a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. […]

Bowman would like to see more weight put on design principles. His blog includes a link to Wikipedia’s article on design elements and principles, which lists:

• unity • harmony • contrast
• balance • repetition, rhythm, pattern • variety, alternation
• emphasis, dominance, focal point • proportion, scale • functionality
• attraction • artistic unity • genuineness in media and form
• proximity • colour    

I don’t think design principles are beyond an engineer. I do think engineers need to be taught how—and when—to think about these details.

As we discovered during the development of Five Sketches™, this kind of detail is often outside the comfort zone of an engineer. However, I can affirm that even engineers who initially produce work with little design insight or creativity have managed to astonish me with amazing design results within a year. And that’s after only occasional participation in Five Sketches™ design sessions.

So, yes, engineers can learn to participate in design, with success and predictability, though I would caution that Five Sketches™ works for engineers because it was developed for and with them, to meet their needs.

At Google, to bring about such a cultural change, Bowman would have needed the unwavering support of at least one senior executive. Even then, as Bowman himself acknowledged in his goodbye message, a company as large as Google does not change direction easily.

If you liked this post, read about how a company’s use of social media influences its corporate culture.

Posted on

Why products stay pre-chasm

I’ve spent some time working with legacy products—software for which the core code was written before “usability” was a term developers had heard of, back when developers were still called programmers.

I remember my first conversation—held last century—with a developer about his users and the usability of his legacy product. The product-adoption curve, with the chasmI used Geoffrey Moore’s book, Crossing the chasm, to introduce the idea that there are different types of users. The chasm (illustrated) shows five groups of users. The area under the curve represents the quantity of potential users, in the order in which they will typically adopt the product. Users who are technology enthusiasts and visionaries either enjoy or don’t mind being on the bleeding edge because of the benefits they get from using the product, according to Moore. Usability isn’t one of the typical benefits to the left of the chasm, where new products are first introduced. Wider adoption follows only after the product is made to cross the chasm—but this takes a concerted effort on the part of the development team.

What delays a product from crossing the chasm?

  • Revenues that are sufficient to let the company putter along.
  • Team members who themselves are tech enthusiasts or visionaries. This occurs, for example, when a nutritionist who also knows how to program develops software for nutritionists.
  • Team members who have infrequent exposure to newer user experiences. This could include someone who still uses Microsoft Office 2003, eschews social-networking applications on the web, or uses Linux.
  • Product managers whose roles are weakly defined or absent, making it more likely that new features get developed for the technical challenge of it, rather than for the user need or the business strategy.
  • Sales reps who ask for more functions in the product in order to make a sale—and a development culture that goes along with this.
  • Managers whose vision and strategic plan leave out user experience and usability.
  • Team members who have been on the team for decades.
  • Organisations that don’t use business cases to help them decide where to apply business resources.
  • Organisations with poor change-management practices—because moving a product across the chasm is more likely dramatic and disruptive than smooth and gradual.
  • Designers who are weak or absent in the process, so that “design” happens on the fly, during development.

If you recognise your work environment or yourself in this list, do you want to change things? If you do, but don’t know how, what actions can you take to learn the answer?

Posted on

Common tasks losing usability

There’s been a loss of usability for people who type text.

Like me, you may have experienced these unwelcome experiences:

  • After typing a long message in Facebook, when I click send, I get a page error and my entire message is lost.
  • After typing a post in WordPress, if the server has gone down or I press an unintended keyboard shortcut, I lose my entire post.

By comparison, if Word stops responding, it will (try to) offer me my unsaved changes when I reopen the document.

With users increasingly doing their work in browsers, why don’t browsers remember the text we were typing? Or why doesn’t the operating system? Or why doesn’t the weblication make backups? Or the server?

When my actions in a browser fail, imagine a message such as this:

Supporting the user after a failure in the browser

This hints at just one possible solution. In the spirit of Five Sketches™, I bet you can come up with at least five more ways to support users after they’ve lost the work they typed in a browser.

Posted on

Which user involvement works

User-centred design (UCD) advocated involving users in the design process. Have you wondered what form that user involvement could take, and which forms lead to the most successful outcomes?

I recently came across data that Mark Keil published a while ago. He surveyed software companies and correlated project outcomes with the type of user access that designers and developers had.

Type of contact with users Effectiveness
  For custom software projects
  Facilitate teams, hold structured workshop with users, or use joint-application development (JAD). ██████████
  Expose users to a UI prototype or early version to uncover any UI issues. ██████
  Expose users to a prototype or early version to discover the system requirements. ████
  Hold one-on-one semi-structured or open-ended interviews with users. ████
  Test the product internally (acceptance testing rather than QA testing for bugs) to uncover new requirements. ██
  Use an intermediary to define user goals and needs, and to convey them to designers and developers. ██
  Collect user questions, requirements, and problems indirectly, by e-mail or online locations. █
  For packaged or mass-market software projects
  Listen to live/synchronous phone support, tech-support, or help-desk calls. ████████
  Hold one-on-one semi-structured or open-ended interviews with users. ██████
  Expose users to a UI prototype or early version to uncover any UI issues. ████
  Convene a group of users, from time to time, to discuss usage and improvements. ████
  Expose users to a prototype or early version to discover the system requirements. ██
  Test the product internally (acceptance testing rather than QA testing for bugs) to uncover new requirements. ██
  Consult marketing and sales people who regularly meet with and listen to customers. ██
  At trade shows, show a mock-up or prototype to users and get their feedback. █
Not reported as effective in this 1995 source
  Conduct a (text) survey of a sample of users.
  Conduct a usability test to “tape and measure” users in a formal usability lab. (This study precedes such products as TechSmith Morae.)
  Observe users for an extended period, or conduct ethnographic research.
  Conduct focus groups to discuss the software.

Although Keil’s article includes quantitative data, his samples are small. I opted to show only the relative usefulness of various methods. My descriptions, above, are long because the original article uses 1995 terms that have shifted in meaning. I believe some of the categories now overlap, due to changes in technology and method. For example, getting users to try a prototype of the UI in order to uncover UI issues sounds like the early usability testing that I do with TechSmith Morae, yet the 1995 results gave these activities very different effectiveness ratings.

For details, see the academic article by Mark Keil (Customer-developer links in software development). Educational publishers typically require a fee for access.

These methods also relate to research I’m doing on epistemology of usability analysis.

Posted on

Put the card in the slot

We know that human brains use patterns (or schemata) to figure out the world and decide what to do. This kind of cognitive activity takes place very quickly, which means we can react quickly to the world around us, as long as the pattern holds.

Here’s a pattern (or schema) that your brain may know: to put a card in a slot, use the narrow edge. If the card has a clipped corner, use that edge. Some examples:
clipped-cards-with-affordance
This pattern is easy for your brain because of the physical cues—also known as affordance. The narrow edge + clipped corner say: “This side goes in.”

A pattern that’s harder for your brain to learn is the magnetic-stripe bank card. You have to think about which way the stripe goes. And it seems harder when you’re in a hurry, or when you feel less safe. Have you used an outdoor bank machine at night, with people hanging around?

Vancouver transit tickets are awful because they don’t follow the card-in-the-slot pattern correctly. As a passenger on the SkyTrain (overhead subway line), you must punch your ticket at the station entrance. The machines are placed so you must turn your back on the drug dealers and their customers who hang out in the subway. As with bank cards, these transit tickets fit four ways, but only one will punch the ticket, and it’s not the edge with the clipped corner. There’s a yellow arrow to assist, but while the arrow is clearly visible in daylight, it’s almost invisible in the yellow-tinged fluorescent lighting of most SkyTrain stations. Also, the yellow arrow must be face down, which is counterintuitive because then you cannot see it. In the photo (above, right), can you find the arrow on the ticket?

Did the designers consider how their ticket machines or bank cards would make passengers feel? Designing for emotion seems to have legs, these days, but it’s not a new idea.

Doing better. I wonder whether the designers of these systems (transit tickets, bank cards) considered all possible options. It’s a Five Sketches™ mantra: You get a better design when you first saturate the design space. This can include doing a competitor analysis to seek out other ideas. And there are other models for transit tickets. I’ve seen Paris subway tickets with the magnetic stripe in the middle, so passengers could insert the ticket face up or face down, frontwards or backwards. The more recent tag-on/tag-off technology used from London, UK, to Perth, WA, avoids the insert-your-card problem—though the overall experience may be worse, since failure to tag off means paying the highest possible fare.

As for bank cards, IBM’s designers must have modelled bank cards on credit cards, which had the magnetic stripe toward the top instead of in the middle. This doubles the customer’s chances of inserting the card incorrectly. An obvious question to have asked at the design stage: can we design a bank machine to read the card regardless of how it’s inserted?

Posted on

Generative design vs. Five Sketches™

© Leah Buley, from her presentation on SlideShareLeah Buley talked about generative design at the South by Southwest Interactive conference today [in March 2009]. Buley feels design methods are lacking in the set of professional tools we use for software development: “We don’t have so many good, reliable, repeatable design techniques.” I agree with her.

Buley tells how, in her first design session at Adaptive Path, she was handed a pen and paper, and told to sketch. The point was “to crank out a lot of ideas in a short time.” That’s what generative design is all about: saturating the design space with ideas. Design programs teach generative design, but there’s no generative design taught in programs for developers, QA staff, technical communicators, product management, or marketing.

There are already several design methods for software development teams to choose from, including Buley’s wonderful grab bag. Others I know of are Five Sketches™ (obviously) and Design Studio, both of which focus on the complete process of producing a design, start to finish, with all its challenges. Microsoft’s Bill Buxton told the UPA 2007 conference that he insists on generative design, and I’d love to see that in action. Each method differs slightly, but they all work because….

Why do they all work? Because of generative design. Generative design addresses what Buley calls her “dirty secret.” She freely confesses, about her design work before Adaptive Path: “I had very little confidence that what I was presenting as the design was in fact the one, optimal solution to the problem.” My experience teaching Five Sketches™ tells me that once you’ve participated in a generative-design process, you’ll know that you can have that confidence.

A related question: when will computer science programs teach Basic Design Methods to developers?

Posted on

GUI: copy it or design it?

I’m a big believer in following the standards for GUI and interaction design. But when do you copy or reuse an existing design, and when do you design something new? Here’s my guideline for when to design and when to reuse or copy the GUI and interaction:

Reuse When… Design
…there is an external standard.
For example: the Vista UX Guide recommends […].		  
…there is a GUI or interaction precedent in your software.
For example: we distinguish between Import and Open.
   …the precedent uses an out-of-date interaction style.
For example: the users cannot drag an object to move it.
  …the precedent uses an incorrect mental model.
For example: user preferences are saved in a text file.
  …usability tests say the precedent reduces performance.
For example: 70% of occasional users do this wrong.
 …the developer wants to re-use existing GUI.
For example: use a variable to change the dialog-box title.
 …competitors have implemented the feature better.
For example: when they zoom in, it’s smooth, not stuttered.
 …the market has a certain GUI expectations.
For example: iPhone promoted gestures, others had to copy.
  …the product requires a certain strategic direction.
For example: all data must be sharable, locally and remotely.
  …there aren’t sufficient resources to design.
For example: “There’s no time in the schedule for design.”

Reuse your existing design ordesign it using Five Sketches™.
Copy the competitor’s design orleapfrog their design.
  If you ship a feature with poor interaction or poor usability, where’s the user value and where’s your credibility? Not all design processes are lengthy. Five Sketches™ takes about a day for most features that you’re tempted not to design.

Here’s an example: did Internet Explorer leapfrog Firefox?