Category Archives: Design

A key element of the software development process is the design phase. These articles relate to the design of software – both program design and interface design.

Making Offshore Design Work

offshore oil rig

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.

Continue reading Making Offshore Design Work

Measuring the ROI of Design

unicorn

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is what happened because of the investment.

Continue reading Measuring the ROI of Design

APR: Information Architecture – Faceted Navigation

facets

In our previous article in the series on the development of nexus, we discussed navigation and information architecture. We identified the challenge of filtering articles by category and by level of experience (beginner / expert), while also viewing the articles along a characteristic (most-viewed, highest-rated, etc). Between both url-creation and visible site-navigation, the challenge we explored was how to present one facet or dimension as primary and others as secondary.

One of our readers presented a third alternative – faceted navigation.

Continue reading APR: Information Architecture – Faceted Navigation

APR: Thoughts on Ratings

thinking in a cabin

Our agile project is to create a site that lets you rate articles. In our corporate goals, we defined the goal to make it easier for people to find and read great content. Last night I was doing some research on social networks and thinking about the nature of our ratings approach. In this article I share some of those thoughts, and the reason for changing the ratings approach relative to previous designs.

Continue reading APR: Thoughts on Ratings

Don’t Make Your Products Too Simple

blocks

Joshua Ledwell wrote a short article expressing his perspective on designing software that is neither too simple nor too complex. He also links to some excellent other articles on the topic.

Designing For Competent Users

We’ve written in the past about how to design for competent users. In fact, it was Joshua’s link to that article that helped us find his article – thanks! Users start out as novices, and most of them become competent users. Very few of them reach a level of expertise with your product. You need to make sure you support both their growth and their likely “end state” – competence. The feature set needs to support the fact that most users end up in a state of competence.

Maximizing ROI

One of several good links from Joshua’s article took us to Luke’s article on the sweet spot for selling software. Luke references an article from the Harvard Business Review and includes an interesting graph that shows the relationships between the number of features and profitability. In short, more features drive higher initial sales by satisfying the buying persona. Fewer features drive higher eventual sales through word-of-mouth marketing based on improved usability.

The HBR suggests a profit maximizing approach of seeking the middle ground in terms of feature quantity. Trying to please everyone tends to result in pleasing no one, so we don’t have a lot of confidence in this approach. But we still like the graph.

Some great thinking out there, what do y’all think in here?

The Wisdom of Crowds Prevents People’s Passions

Passion

The wisdom of crowds helps us avoid stupid decisions. Unfortunately, it also prevents innovative, passionate, fantastic decisions. Collective Intelligence is collective insipidness. We need to keep the inputs of individuals in the mix.

Collective Intelligence

Collective intelligence is the notion that a group of individuals will be smarter than a single individual. The old adage, two heads are better than one, is extended to mean several heads. Kathy Sierra goes on a bit of a rant about how this (narrowly applicable) idea has been twisted into the idea that mobs are better at designing stuff than individuals.

Design By Committee

Since we’re breaking out the old saws, we should acknowledge that people also have known for a long time that design by committee is a bad idea.

Eliciting and managing requirements requires communication, and prioritization. Both of these involve collaboration. When we collaborate, we risk introducing the negative effects of collective insipidity [If I were collaborating on this article with a group of other people, they wouldn’t let me use the “word” insipidity].

Brainstorming involves collaboration in the requirements gathering phase of a project.

Prioritization also involves collaboration. We can prioritize the ideas from a brainstorming session, or we can prioritize requirements, or the sequence of use case delivery. Basically any process that involves filtering or sorting is a prioritization exercise.
Kathy concludes her passionate article with a great quote:

No matter what, I believe that in our quest to exploit the “We” in Web, we must not sacrifice the “I” in Internet.

So how do we avoid the dillutive effects of the crowd’s concensus?

Dictators Dodge Dillution

One way is to follow apple’s model – have a dictator. As long as the person calling the shots has good instincts, she’ll make good decisions. If she doesn’t, we’re toast. With this approach, we get both the downside (possible bad decisions) and the upside (possible great decisions).Another approach is to allow passion to stand out, when interpreting the inputs of the masses.

Weighted Prioritization

We wrote an article last September with tips to maximize the benefits of brainstorming.

The idea starts with having people vote on the ideas that were generated in a brainstorming session. This alone is a mathematical embodiment of the commonness of crowds. We end up with the lowest common denominator.

We then added the notion of “voting again with a 5X impact” on those items people feel passionate about. This allows the strongly held notions to compete with the universally not-unappealing ones. Read the article for more details.

Bypass Brainstorming

The guys at OK/Cancel are super effective at creating great content. They do it by using idea seeding instead of brainstorming.

In a nutshell, the two of them collaborate with an iterative process that involves creating ideas independently, transferring “ownership” of those ideas to each other, and then improving upon them. Really a novel concept – check it out.

Conclusion

Crowds can be leveraged to prevent mistakes. They can’t be leveraged to create greatness. Crowds serve to filter out the extremes on both ends. There is value in avoiding the mistakes, but the cost of avoiding greatness is too high. Whenever we bring in the crowds, we have to keep the individuals in the loop too.

Fifteen Ways to Shut Down

shutdown

[Updated Below] There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Hat Tip

Joel (on Software) has an article where he lambastes the Vista team for providing 9 different ways to stop using the computer. Add in the hardware options on the laptop (like Fn F3), and closing the screen down or hitting the physical power button, and you get to 15 different ways to shut down.

Inevitably, you are going to think of a long list of intelligent, defensible reasons why each of these options is absolutely, positively essential. Don’t bother. I know. Each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.

Joel Spolsky

Make Everybody Nobody Happy

Joel posits that the unreasonable number has grown out of the desire to make everybody happy. We know that too many features makes everyone unhappy. This bloated list of choices is just one manifestation of too-many-features, and it doesn’t make anyone happy.

Inadvertantly Causing The Problem

It is pretty easy to imagine how we might inadvertantly cause this problem.

A structured requirements approach allows us to track and manage different requirements, as well as the implementation of those requirements. In Joel’s example, imagine requirements like the following:

  • User secure the computer in order to walk away from it without other people getting access.
  • User can shut down the computer such that it will stop consuming power.
  • The computer will support rapid switching from one user to another.

Each requirement could drive an independent solution approach. As Joel points out, each requirement, evaluated in isolation, may lead to a different solution. The problem is that we are finding local optima, and not looking at the problems introduced by the complexity of supporting all of these solutions.

Avoiding This Problem

How can we avoid this sort of problem in our own product development? A holistic view of the proposed solution is required to assess if there are too many features. Prioritization of those features will help us reduce the number to a reasonable level.

Incorporating elements of interaction design into our solution approach may be the best way to do this (short of abandoning a structured requirements approach).

ID and Structure

Each of the shutdown scenarios leads to a functional requirement. Each element of program design leads to one of the many ways to shut down or lock or restart the computer. Addressing the personal goals of each persona provides us with a cross-feature, holistic perspective. If our target audience includes Joel’s uncle, then we can make sure that our design approach accounts for the appropriate level of complexity and choice.

[Update]

Moishe Lettvin, one of the developers on the shutdown team for Vista, formerly at Microsoft, has written an article about the organizational and situational challenges faced by the team. He titled the article The Windows Shutdown Crapfest. That should give you a feel for how the now-Googler feels about the experience. There were 43 people involved, and they spent over a year. And the source code control system was frightening. Check out the comment thread on Moishe’s article too – it includes comments from other Microsoft and knowledgable anonymous people. Hat Tip to Scoble. Also, a followup from Moishe.
Summary

Multiple requirements can lead to multiple, locally-optimized solutions or features. A holistic view needs to be taken to assure that we aren’t introducing too much complexity with these variations of similar features. Interaction design gives us a big-picture perspective to make sure we aren’t making our software too hard for our target users to use.

Goal Driven Upgrades

upgraded seat

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.

Background On Documentation

Over the last couple of days, we’ve written about how to structure documentation to define what users can do with the software, instead of capturing what the software can do for users. This reverse approach uses user goals to guide our documentation. We also presented, more concretely, how to trace and manage our goal-driven documentation with use cases.

We can leverage this documentation approach to achieve two additional benefits:

  • Encourage users to install new upgrades
  • Encourage users to migrate from other applications to ours

The same factor is at play in both situations – users already know how to use their existing software, either a previous version of our software or a competitors software. The fundamental question for users is “How will I do what I need to do?” This is a major barrier to both upgrades and migration from other applications.

Kathy On Upgrades

Kathy’s article on why users don’t upgrade is awesome. She creates a great visual graph (shared via her CC license) of the user’s perspective on upgrades:

Sierra's Graph

Why they don’t upgrade (and what to do about it)

Kathy goes on to list several approaches to address the problem, all of them fall into either “make them want it” or “make it easier.” We will focus specifically on how writing goal-driven documentation can help.

Make Them Want It

We must apply the same prioritization approach to defining upgrades as we do to defining the initial release. This assures that the most valuable not-yet-implemented goals are addressed in the new version of the software. If we are using Kano as a framework for prioritization, we have the added benefit of effectively lowering the suck-threshold.

Make It Easier

We can make design decisions that make software easier to use. We can also follow Kathy’s other good suggestions. And we can write our documentation to make it easier for users to make the change.

Goal-driven documentation has two effects on the curve Kathy drew above. Here’s the same curve, representing a typical software upgrade:

typical upgrade

With goal-driven documentation, the curve is shifted up and to the left:

shifting the curve

This shift can be analyzed as two different factors:

two factors

The goal-driven documentation allows users to climb become more competent more quickly – effectively lowering the suck-threshold. When applied to upgrades, it reduces the size of the drop – preventing users from re-entering the suck-zone.

Faster Climb

Competence is not a measure of how quickly users can do everything the software can do – it is a measure of how quickly users can do everything they need to do with the software. When we define our software to prioritize solving the most valuable problems for our customers, we are defining the set of activities that the users need to do. And we identify this as a set of use cases.

We then document how users will follow those use cases, with the implementation we’ve given them.

structured doc

This goal-driven approach to documentation helps users climb the competence curve much faster, immediately reaching the “Finally I can actually DO something” point (above the suck threshold). As long as we document the right somethings, we’re all set.

Shorter Drop

We apply this same approach to our upgrades. Those use cases that we’ve added in a new release yield new documentation. Those implementation areas we’ve modified as part of the upgrade yield updates to previously released docs.

Users will have an easy answer for “how do I do it now?” as well as “What can I do now?

Collateral Benefit

We also get the benefit of making it much easier for users to migrate from other software packages (not just our earlier releases). There are books out there where authors address exactly this problem – Microsoft Word for Wordperfect Users and Java For Cobol Programmers come to mind. By showing users how to do what they need to do, we make it easy for them to switch.

Conclusion

  • Goal driven documentation makes it easier for users to learn how to use our software.
  • Goal driven documentation makes it easier for users to switch from other software programs to ours.
  • Goal driven documentation makes it easier for users to upgrade to new versions of our software.

Use Case Driven Documentation

drilling

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.

Our proposed documentation approach is to write about what users are doing with the software, not what the software can do for the users. Using a power drill as an example, we proposed the following representative approach:

  1. How to drill a hole in a flat surface (wood or plastic, metal, masonry).
  2. How to select the right screw for fastening items.
  3. How to drive screws (phillips, flat-head) with your drill.
  4. How to stir paint with your drill.
  5. etc…

Suddenly, the documentation is helping us to achieve our goals.

Extending Structured Requirements

When we use a structured requirements approach, we have established a framework for defining the problems that our software will solve. We articulate how people solve those problems with use cases. These use cases define exactly what we need to document.

When we view structured requirements, they look like the following diagram:

structured requirements

From Non-Functional Requirements Equal Rights Amendment

We extend this structure by leveraging the fact that the use cases identify the highest priority tasks that users will perform to achieve goals. These are therefore the highest priority tasks to document. The documentation represents how a user would achieve a use case, with the implementation that we’ve created.

structured documentation

We can even trace each portion of our documentation work to the use case that it supports.

Extending Interaction Design

With interaction design, we are again focusing on what people intend to achieve while using our software. Even if we are writing game software (which is designed to be played without a “goal” in the traditional sense), the user still has a goal of “being entertained.”

With interaction design, we would write documentation that demonstrates the way that scenarios play out with the given implementation that we created.

Even when combining interaction design and structured requirements into a hybrid approach, we still have a source from which to define our documentation needs – the scenario.

Summary

We’ve previously defined the benefits of documenting what users do with our software instead of documenting what our software can do for users. In this article we present a framework for defining and tracing that documentation – building upon use cases or scenarios. This documentation approach makes for software that is easier to use, and therefore better.

Flesh Out Those Wireframes

Wire frame man(John Richards)

Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.

Hooked From the Start

Stephen starts his article with the following quote…

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

A very solid opening to his position that when you only use wireframes, you introduce problems. Wireframes are designed to eliminate problems and “clutter” from the feedback session. Feedback sessions provide us with a lot of information, and the challenge is to separate the noise from the signal. The goal of wireframes is to eliminate sources of noise, to make it easier to focus on the signal. But using wireframes also introduces noise into the data.
He goes on to provide a real world example of a website under development for Verizon – showing wireframes and “low fidelity prototypes” that include more information than just the wireframes.

Why Wireframes?

Stephen makes an interesting point – wireframes (named after 3D modeling techniques) were initially designed to provide quick feedback and insight into 3D models, without the expense of complete rendering. As technology reduced the cost of of rendering, rendering cycles began to replace wireframes as early prototyping tools.

A wireframe, in the user interface world, is a minimalist visualization of a website or application. It shows where information will reside on a page, and what information will be shown. When using a wireframe to get feedback, it allows a designer to (attempt to) isolate the feedback about content and layout from other data (like feedback on color schemes and graphics). It also allows for more rapid prototyping because the prototype can be built as soon as a layout is done, without waiting for colors and graphics and branding to be incorporated into the design.

Why Not Wireframes?

Expanding on Stephen’s point, the lack of information detracts from an understanding of the usability of a design. Colors (such as blue hyperlinks) do provide visual cues for users. Branding and navigation elements provide a sense of context and comfort. The absence of these things can distract the people we were trying so hard to not distract.

What About Cost?

Another goal of using wireframes is to reduce the cost (and time equals money) of prototyping. Stephen shows how in less than 15 minutes, a wireframe prototype is converted into a prototype that leverages existing branding, navigation, colors, and images. 15 minutes is not a long time to spend to achieve this striking difference (check out the images in Stephen’s article). When showing multiple screens in a site with structured navigation, most of those investments will be re-used across multiple screens.

Why It Will Work

The ability to re-use the “extra bits” is the key to why it will work and not just the key to why it won’t cost more.

People who think about website advertising worry a lot about ad-blindness, or the ability of people to ignore ads over time. We actually depend on it here, to allow our regular readers to tune-out ads that appear in consistent locations and formats and instead focus on the content of the articles. This same phenomenon applies to these augmented wireframes.

The lack of context that a wireframe creates can be disconcerting or even confusing. The (valid) concern that drives the use of wireframes is that providing all the other stuff will distract the users and prevent them from providing feedback on content and layout.

The ad-blindness effect will quickly allow people to ignore the “other stuff” and focus on providing feedback on the content and layout of a page. People are good at scanning pages – they have an autopilot that takes them directly to the “meat” of the page. And the presence of the extra content allows them to do that – where the absence of that richness will immediately trigger a “what’s wrong?” or “what’s different?” analysis.

manikin

Tips to Making It Work

Stephen provides eight tips, which we really like. We are concerned about one of the tips – to use “real data” instead of fake data. I had always learned that real data risked distracting the users, who might fixate on the fact that you chose incorrect data to display.

Today, after a prototype review session, we got feedback from our reviewers that it would help them if we used real data.  The reviewers of our (fleshed out) wireframes were unable to visualize how the interface might behave with some real-world data examples. The data we were presenting and manipulating is fairly complex, and the contrived examples didn’t do a very good job of showing how the interface would handle the complexity it would need to support.

Using representative data is definitely a good idea – and as good as Stephen’s other ideas are, we’ll take his word for it that real data is even better.

Conclusion

Spend the incremental effort to make wireframes “feel real” by fleshing out some of the context that wraps the prototyped pages. That context will provide more comfort than distraction for users.