Category Archives: Software Engineering

Are you missing an assembly reference? Why, yes I am. So kind of you to ask.

Ever pull down the source code for a project, only to find many errors of the “The type or namespace name ‘Optimization’ does not exist in the namespace ‘System.Web’ (are you missing an assembly reference?)” variety?

This just happened to me because I pulled down the Page of Photos source code from github for the first time to a certain dev machine. Not all of the binary library dependencies are checked into github (trying to just check in source code), so how does this happen and how should it be fixed?


In my experience, this usually relates to NuGet packages. There are at least two reasonable solutions.

Solution #1: Capture All Binaries (not recommended)

Check into source control the binaries for those packages your project depend on so they’ll always be there. Personally, that seems so last year, and I don’t take this approach for libraries available through NuGet.

(Having private libraries is no longer a reason to do this either. Check out MyGet,org for a hosted private solution that works fine with NuGet machinery.)

Solution #2: Empower NuGet to Self-Heal

Right-click on the Solution from the Visual Studio Solution Explorer and notice the two NuGet-related options in the pop-up menu. To fix the problem imageat hand in the most convenient manner, simply select “Enable NuGet Package Restore” which is the second of the NuGet-related options.

You will then get an explanation of what’s about to happen:


If you choose “Yes” then NuGet will think for a few seconds before declaring victory:


You might notice there are some new NuGet-related artifacts in your solution.


Now if you again right-click on the Solution from Visual Studio’s Solution Explorer menu, you will notice that the “Enable NuGet Package Restore” menu is gone, leaving only the “Manage NuGet Packages for Solution” option. Select the “Enable NuGet Package Restore” menu to bring up the NuGet management dialog.


Click on “Restore” and your solution should begin to heal itself by downloading the many missing NuGet packages. You can feel the excitement as NuGet thinks it through..


.. and thinks some more ..


.. then – Ta Da! – you suddenly have a bunch of downloaded libraries.


Now your solution will happily compile once more.

Note that this is a one-time & long-term solution since now NuGet is empowered to pull down missing packages whenever needed. (Not “any old packages” of course – just those you’ve added to the projects within the solution.) When you freshly pull down a build (just the source) from source control it helps, of course, but build machines will also enjoy this.


C# Exception Handling: Accessing the Base Exception

Sometimes the mundane act of giving a concept or feature a good name goes a long way in simplifying it and making it easier to grapple with. Even if it is just a small time-saver. The Base Exception concept in .NET exception handling is a good example – one that we’ll return to shortly.

When handling exceptions in C#, sometimes you will find that the exception you see in your catch block holds a great deal more data than you might realize at first glance.

The most obvious is the Message property which might explain what happened (in prose), or perhaps the HResult property which might explain what happened (after reviewing documented return codes, or perhaps after a Google search on the returned value).

Further, different Exception types may also have additional specialized properties, such as the ParamName property on the ArgumentNullException class.

And then sometimes there is the motherlode of additional exception data: an inner exception. When the InnerException property is not null, it contains a copy of an entire additional exception, usually one more specific than the one you caught directly. And an InnerException property can contain its own InnerException property, creating an arbitrarily deeply nested chain of exceptions.

This can be invaluable information, but how do you dig out the most deeply nested one – since that’s most likely the exception that started causing trouble in the first place.

You basically have two choices.

Choice #1 – dig it out “by hand” using a loop:

catch (Exception ex)
   var baseEx = ex;
   while (baseEx.InnerException != null)
      baseEx = baseEx.InnerException;

Or Choice #2 – and the better choice – is to realize that there is a name for this exception – in the .NET Framework it is known as the Base Exception – and simply ask for it by name. All Exception and Exception-derived classes have a GetBaseException method.

catch (Exception ex)
   var baseEx = ex.GetBaseException();

I’ve found that in debugging Windows Azure Cloud applications, jumping directly to the Base Exception is often a productive first step in zooming in on the root cause of the issue at hand.

Hopefully this post gives you some insight into more efficient understanding of exceptions in your own applications – and a small helper in digging out the Base Exception.

Visual Studio Ultimate 2012’s “Generate Dependency Graph” helps quickly visualize system dependencies

Recently I was exercising some of the OData APIs for manipulating a Windows Azure Access Control Service (ACS) namespace. I found some nice sample code, but the sample code was super-extensive (even including a Windows Phone sample), but my needs were humble (I wanted to manipulate ACS Reply-To addresses). After cutting out a few of the obvious projects so I could find “the code that mattered” I was still left with a heap of projects and libraries to weed out to get to the essential code – and it was tedious and error-prone to manually do this (if I was too aggressive, I broke the solution so it would no longer build). Frustration! How could I efficiently zoom in on the code I cared about so I could ensure I understood its requirements and dependencies?

This was two easy steps:

1. Create a simple program to exercise the code I cared about. This was a Console app I called TestRealmLib.exe.

2. Figure out everything that TestRealmLib.exe really depended upon.

Step one was easy since I knew the functionality I wanted to exercise.

Step two was easy once it dawned on me to use the right tool for the job: Visual Studio Ultimate 2012’s Generate Dependency Graph tool found under the ARCHITECTURE menu option.

NOTE: My understanding is that this feature is only fully available with Visual Studio Ultimate 2012, partially available in Premium (view but not create), and not available in lower editions – compare what’s included in which Visual Studio editions here: I only have personally used it with Visual Studio Ultimate 2012 on solutions with C# projects (though I understand C++ is also supported, and assume any .NET language would work as well).

Running this for the whole solution, and rearranging the nodes with my mouse, quickly let me see where all the dependencies were.


I was quickly able to see that the modules I dragged to the right-hand side of the graph were not necessary, and those few on the left were the key. That was the answer I needed, but there are other interesting features. For example…

The thicker dependency lines represent more dependencies than the thinner lines. To drill in, right-click on a dependency line. Here’s what you get when you choose Advanced > Show Contributing Links on New Code Map:


Also note the “red dot” in the Code Map – this is indicating that I currently have a breakpoint set in there – yes, this is debugger-aware.

There are a bunch of other nifty features with this that you can check out here. These include dependency analysis, “Show Contributing Links” (on the dependency VisualStudioDependecyGraphWithLegendlink to show which parts of module you are calling), and more. The UI gestures you’d expect all do something reasonable – like double-click, right-click, whether on nodes or lines. You can double-click a class or method name to jump to your C# code. And don’t forget to turn on the Legend (from toolbar at top of graph, not shown in my screen grabs) and explore the other features.

There is also a nice video demonstration in Channel 9:

Introducing the Boston Azure Project

Cloud Computing on Microsoft’s Windows Azure platform is still new, but will be big. I believe that. That believe fueled my interest in starting the Boston Azure cloud computing user group (henceforth in this blog post, simply “Boston Azure”) back in the fall, even before Azure was released. Boston Azure is a cloud computing community group focused on learning about Azure.

Currently Boston Azure meets monthly on the 4th Thursday of the month in Cambridge, MA in the USA. This is an in-person meeting. I have received a loud and clear vibe from the Boston Azure membership that there is a thirst for more hands-on stuff. That was fueled further first by the hands-on Azure SDK meeting we held April 29, then again by the all-day Firestarter held May 8. But we need more. So, I had this idea for an ongoing community coding project that we can hack on together at Boston Azure meetings and other times… I bounced the idea off the community at the May meeting… since I received a really positive response, I now officially declare I plan to go ahead with it…

Introducing the Boston Azure Project

Why are we doing this Project?

The community wants to code. There is a desire to learn a lot about programming in Windows Azure – and what better way to get really good at programming Windows Azure than by programming Windows Azure.

The primary goal of the project is to learn – to get good – really good – at Windows Azure.

How will the Project work?

To be hands-on, we need a project… so here’s a project to provide us with focus:

We shall build a “gently over-engineered” version of

This “gently over-engineered” version of

(a) will provide a productive environment where participants (developers and otherwise) can learn about Azure through building a real-world application by contributing directly to the project (through code, design, ideas, testing, etc., …), and

(b) will do so by taking maximum advantage of the technology in the Windows Azure platform in the advancement of the web site (though thinking of it as “just a web site” is limiting – there is nothing stopping us from, say: adding an API; exporting OData or RSS feeds; being mobile-friendly for our visitors with iPhone, Android, and Windows Phone 7 devices; etc.), and

(c) will serve the collaboration and communication needs of the Boston Azure community, and

(d) will provide an opportunity for a little fun, meet other interesting people, and enhance our skills through sharing knowledge and learning from each other.

When will we code?

We will reserve time at Boston Azure meetings so we can collaborate in-person on a monthly basis. Participants are also free to hack at other times as well, of course.

Wait a second… Does it make sense to port a little web site like to Azure?

It does not make sense – not in isolation. Go ahead and crunch the numbers on Windows Azure pricing and compare with an ISP-hosted solution. However, this is the “gently over-engineered” part: we are doing it this way to show off the capabilities of Windows Azure and learn a bunch in the process.

What is the output of the Project?

This project will be feature rich, easy to use, accessible, flexible… and open source.

Keep in mind: Since is the web presence for Boston Azure community…

It Has To Work!

This project is for and by the community.

Anyone can contribute – at any seniority level, with any skill set, with many possible roles (not just developers).

Then how do we reconcile anyone can contribute with it has to work? The community process needs to be able to make the code work before we put it into production. We have to make this work. And we will.

So, now you’ve heard it all – the whole idea – at least the Big Picture. I will post more details later, but for now that’s it.

Next Steps

Please contact me (on twitter or by comment to this blog post or by email) if you want to be one of the very first participants – I would like a couple of folks to be in a “private beta” to get some details squared away before I make the CodePlex site public.

Update 23-June-2010: The project is now live on CodePlex at

Software Development Lessons from the Movie Industry

Which is more important: Good People or Good Ideas?

The following video of a talk by Edwin Catmull, Ph.D., President of Pixar, is loaded with insights from the Movie Industry (specifically Pixar Animation Studios) that are applicable to those of us in Software Development – in fact, applicable to those of us in any team-oriented endeavor of any complexity. Every technologist who works on a team should listen to the talk. Then listen again. Any place where he talks about movies, substitute Software Development (or your team-oriented, complex vocation of choice) and think about how it applies to you.

Dr. Catmull ultimately answers the question of which is more critical: good people or good ideas? In doing so, he concludes unequivocally that People are more important, but doesn’t stop there – it is really those People on Effective Teams that makes the difference.  He also peppers the talk with interesting insights, such as competitors (in all industries) are always copying ideas – but often they copy the wrong ones – they tend to copy only ideas that were previously well executed (and, thus, usually successful), but should perhaps pay more attention to the far more numerous good ideas that were poorly executed.

Successful products have got thousands of ideas. There’s all sorts of things necessary for it to be successful. And you have to get most of them right to do it. That’s why you need a team that works well together.
-Ed Catmull, Ph.D., President, Pixar Animation Studios

I stumbled across the video when reading a post by Jeff Atwood admonishing us to Cultivate Teams, Not Ideas; Jeff’s post is also worth a close read.

Notes and Quotes

Notes I took of Ed Catmull’s illuminating talk follow – mostly direct quotes (prefaced with where in the video it occurs):

  • @ 10:45 “We had confused the orgizational structure with the communication structure – a very common thing that happens to a lot of companies. They are different.”
  • @ 13:30 “success hides problems
  • @ 15:25 (on doing “A” bug’s life and “B” toy story/direct-to-video) “We shouldn’t be thinking that it’s okay to be doing something that isn’t great.” (so they stopped the non-great ones)
  • @ 21:55 “What’s the central problem, finding good ideas or finding good people?” – answer is very clear:
  • @ 22:07 Teams are more important than ideas: “If you have a good idea and you give it to a mediocre group, they’ll screw it up. If you give a mediocre idea to a good group, they’ll fix it, or they’ll throw it away and come up with something else.”
  • @ 22:27 “We think about ‘an idea’. When we think of ideas for movies, we think about ideas for products. And it’s usually thought of as some singular thing. But the reality is, these successful movies – as well as successful products – have got thousands of ideas. There’s all sorts of things necessary for it to be successful. And you have to get most of them right to do it. That’s why you need a team that works well together.
  • @ 23:49 On teams that function well together as a key competitive driver.”On the way we measure progress, is on how well that team gets together.”
  • @ 23:57 “The first time you do it, it’s a mess.”
  • @ 24:07 “The only failure is if you don’t learn from it – if you don’t progress. So the way you measure it, is this team functioning well together? And it’s a thing that’s never let us down. When that team functions well together they will succeed. When things are going wrong, they will fail.
  • @ 25:00 “People like to copy the wrong things.”
  • @ 25:25 “They always remake good movies. And rarely do they beat the good movie. But the fact is, there are thousands of movies out there that are actually great ideas, but are poorly executed. They should be remaking bad movies.”
  • @ 25:38 “How does it happen with products – the ones that do better are the ones just copy somebody else’s good product, they actually take the thing that’s going wrong and fix that. That’s the better idea.”
  • @ 25:52 “They could copy the technology, but they couldn’t copy the process we were using to come up with the story.”
  • @ 28:07 (on post-mortems) “Get a lot of facts about the process. When you put the facts up, and you are fact driven, it actually stimulates discussion. And it’s those discussions that are very valuable.”
  • @ 28:39 “Summarize a few of the things we’ve learned:
    1. Constant review
    2. It must be safe for people to tell the truth
    3. Communication should not mirror the organizational hierarchy
    4. People and how they function is more important than ideas
    5. Do not let success mask problems; do a deep assessment.”
  • @ 29:55 “Everybody says that the story is the most important thing, even if the story was drivel. It might be true – in fact, it is true – but it doesn’t effect behavior.” “Subscribe to Email List” Form gets UX make-over

There is a “subscribe” form on the Boston Azure web site from which people can ask to be added to  the group’s email list.

I just made some updates to improve the user experience (UX). Here are the changes I made, and I list the handy web resources I used to help me decide (where applicable).

For field labels, I place the label directly above the field it describes. I use <fieldset> and <label> to describe my markup, presumably making it friendly to screen readers. (Credit to templates provided with ASP.NET MVC for making this part easy.) This is the layout that Luke Wroblewski (author of Web Form Design: Filling in the Blanks) recommends in his Best Practices for Web Form Design for scenarios where you want to maximize speed, and the user is likely familiar with the data being requested.

Luke’s work is packed with clear, actionable, useful guidance that is easily applied and backed by user research. A gold mine…

Other recommendations I adopted from LukeW include:

  • Since I have two required fields and three optional ones, I removed the (Required) labels, and stuck with the (optional) ones only.
  • Added field length for optional Notes field.
  • Made the Primary Action of the form (the Subscribe button) green, just like Apple Store (got the idea from UIE mailing).

Also from LukeW, but from a different source (The Apple Store’s Checkout Form Redesign, which I learned of from a UIE mailing):

  • After the form is submitted, the user does not get an immediate email. I made that clear in the resulting text.

More improvements I can make in the future, also based on LukeW, include:

  • Validate the data entered. In my case, this is currently only that a well-formed email address is provided.
  • Provide more context on why data is being requested.
  • Disable the Submit (Subscribe) button after it is clicked to avoid double clicks.

Other changes, outside of LukeW’s guidance:

  • Mentioned “low volume” and “will not spam you” – though also need a privacy policy. Will get to that eventually..
  • Programmatically set focus to the first field in the form when the page is loaded. I used the jQuery technique described here.
  • Dropped “:” (colons) at end of labels while also changing labels text from leading caps style to mixed case (“Job title” instead of “Job Title:”). While not decisive for me, I found an interesting discussion around whether to use a colon in form labels.
  • Made sure users could press Enter at any time to submit – but this will only work if they are not in the single multi-line field on my form. Need to consider removing that field … Need to consult with Joan on that one. 🙂

Used semantic mark-up to implement the green Submit (Subscribe) button mentioned above:

Green button that is visually distinctive

Submit (Subscribe) Button


<input type="submit" id="primaryaction" value="Subscribe" />


 padding: 5px;
 color: #FFFFFF;
 background-color: #267C18;
 font-weight: bolder;

Old form:

sign-up form BEFORE the make-over

New form:

The subscribe form AFTER IMPROVEMENT

The AFTER screen shot

Steve Krug on Rocket Surgery Made Easy from Dec 2010 BostonCHI Meeting

Rocket Surgery Made Easy

Steve Krug speaks at BostonCHI

Notes from 08-Dec-2009 meeting

  • Steve’s new book – Rocket Surgery Made Easy – due in bookstores in a couple of weeks – material from this talk will be in his book…
  • Passed a copy of his book around through the audience for quick peek
  • 150 or so people in attendance

Writing process

  1. writing process: collect years of notes
  2. need deadlines to force you to write (and finish)
  3. collect relevant articles for each chapter and post them all on a wall
  4. once you’ve begun to panic, start throwing things overboard
  5. Outline, write, iterate
  6. get help
  7. throw things overboard (save for next book?)
  8. FAQ at the end of every chapter – good idea
  9. Doing usability (vs How to Think About Usability)

Doing Usability

  1. A morning a month – that’s all we ask
  2. Run tests – with whole team – at our site – scheduled monthly and well ahead of time – and debrief immediately after over lunch
    1. maybe do right before iteration planning
    2. company-sponsored lunch
  3. Start earlier than you think makes sense
  4. The sooner you get information, the better use you can make of that information
  5. Don’t wait until the site is “finished” – test it as soon as it is testable
  6. Don’t worry that “you already know about the problems”
  7. If you have nothing built, test other people’s sites
  8. Are you working on the site? –> Yes ==> test now!
  9. Recruit loosely and grade on a curve
  10. Beware implied domain knowledge
  11. Some testing can be done w/o your target audience
  12. Usability testers say many things that are similar to what therapists say – “what did you expect to happen when you did that?”
  13. Keep yourself out of it! It is about the user and what the user being tested is thinking.
  14. Make it a spectator sport
  15. Get everyone to come and watch the test – frequently the observers suddenly just “get it” that they are not their users
  16. Have high quality snacks. Keep the sessions short and compact. Do them on site. Make it easy for everyone to join in, hard to have a good reason to skip it.
  17. Record sessions with Camtasia ($300). Get a good USB desktop microphone ($25). Don’t record user’s face (“useless and distracting”). Use a screen sharing service (like GotoMeeting, $40/month?) to control the UI. High quality audio is important, and should be channeled to the observation room via GotoMeeting or Skype.
  18. Focus ruthlessly on a small number of the most important problems
  19. Serious because everyone will come across them, or serious because for those who do encounter them will be seriously impeded.
  20. Don’t feel you need to come up with the “perfect” fix
  21. Ask everyone in the observation room to write down the three most important issues they observed. These are raised at the debriefing session over lunch.
  22. When fixing problems, always do the least you can do ™
  23. Prioritize the list, then work your way down the list until you run out of time/resources
  24. Sometimes a tweak is better than a redesign – don’t get suckered into a redesign – the perfect is the enemy of the good!
  25. Focus on the smallest change we think we can make to address the problem we observed
  26. Q&A
  27. Remote Testing?
  28. Remote testing is handy – saves travel time, recruiting pool grows, … do over skype or GotoMeeting.
  29. How to get it off the ground? Try a group usability test of competitor’s site – everyone can get behind that. Do one and hope people get enthused about it. Make the cost of swinging by to watch the testing really small.
  30. Be very cautious about asking users how to fix the problems they’ve encountered. “Users are not designers.” “Hopefully you know a lot more than they do about design.” Listen to them, but be careful that they’re ideas are not well thought out. The purpose of testing is to “inform your design intelligence”.

The Fountainhead of Open Source

Just watched the The Fountainhead movie from 1946 (yes, from netflix).

Howard Rourke hacking Open Source code

Howard Rourke hacking Open Source

Here is the plot summary, brought up-to-date:

  • Open Source is represented by the protagonist, a brilliant architect named Howard Rourke. Rourke is idealistic, does his own thing, is uncompromising, and is not driven by money or recognition – and certainly not by Big Business.
  • Big Business is  represented by newspaper magnate Gail Wynand. Wynand wields substantial influence and is in perpetual pursuit of any means to incite the populace – an energized populace buys more product.
  • Consultants and Certified Vendor X Developers and Vendor Partners are represented by  architect Peter Keating. Keating goes with the flow, producing whatever the powers that be say is desirable. At one point, he mentions to Ms. Francon he’s polling folks on what they think of Rourke’s latest building to which she responds (with some disdain) “why, so you’ll know what you think of it?”


  • Talent != influence. Keating’s influence is limited to those who recognize his greatness. Most only recognize as great what they are told to recognize as great.
  • Passion can be directed constructively (Rourke pours his love into his life’s work) or destructively (Wynand devotes his career to controlling the masses through his newspaper).

The movie is based a book of the same title. The author, Ayn Rand, became well known for her Objectivism philosophy of life, exemplified in the movie by Gary Cooper who played the lead character, Howard Roark. [I wonder what Richard Stallman thinks of the book?]

I wonder how many professional software developers identify more with Howard Rourke or Peter Keating? And which is more desirable?

Any my clean analogies fall apart when one considers the combinations of Big  Business and Open Source. Microsoft just announced and the CodePlex Foundation “to enable the exchange of code and understanding among software companies and open source communities.”

A dirty little secret of Eclipse, Linux, Apache and other high-profile projects is that they also have professional, full-time staff – sponsored by Big Business (like IBM) – since the success of these endeavors is strategic for their business.

Maybe Open Source isn’t as pure as the romantic notion of developers from around the world contributing since it was a nice thing to do. The world-wide altruistic contributions may still be there in some cases, just supplemented by Big Business. Which is okay with me, though might not be with Howard Rourke.

Continue reading

Jared Spool on what makes a UI Intuitive

Jared Spool spoke at a Refresh Boston user group meeting on Thu May 28 in Cambridge, MA. During his talk, which was titled What Makes a Design Seem Intuitive?, Spool delved into some common ways User Experience (UX) goes wrong and some ways to make sure this doesn’t happen to you. My personal notes/interpretations follow; if you think I got it wrong or want to offer alternative interpretations, feel free to comment.

Executive Summary

  • Understand your users and their levels of skill/knowledge 
  • Understand the skill level needed by users of your software
  • Identify any gaps between the actual and needed skills (see two points above)
  • Design the software to bridge these skill gaps (which may vary from one user to the next)
  • Test your assumptions with real users to make sure you did everything right (Yogi Berra was right when he said You Can Observe A Lot By Watching!)

How to Create Non-Intuitive User Interfaces

First, some counter-examples – easy paths to UX Failure – how to be Non-Intuitive:

  • Do the unexpected: Spool showed an example of a site that used * (asterisk) to indicated those field “not required” which is opposite of popular convention. UX Fail.
  • Implement non-standard & sub-substandard behaviour: Spool showed a beautifully designed (visually appealing) site  with custom scrollbar that didn’t work right (pretty but not functional). They had implemented their own scrollbar functionality to get the look they wanted – but a fully-functional scrollbar is really hard to do well – theirs was jerky and unpredictable. UX Fail. (Plus a bonus Form Follows Function Fail.)
  • Be non-intuitive: Spool showed “Hay Net” – a very simple site to help sellers and buyers of hay find each other. This site had two main choices on the front page – “have hay”, “want hay” – but user testing showed that about half the time “have hay” was chosen to find someone who has hay, and the rest of the time chosen when I am the one who has the hay. (This might qualify as what my old friend Julianne would call “Escher words” – where the meaning flips back and forth in your mind between alternative viable interpretations much like certain of M. C. Escher‘s artwork). Wording was not intuitive, even though it was very simple. UX Fail.
  • Add non-core features until your application is large and complex: The larger and more complex an app, the harder it is to keep it intuitive. This was a general comment from the Q&A, supported by examples in his talk [Wang dedicated word processors were very complex (requiring 1-2 weeks of training to use), supplanted by WordStar, supplanted in turn by simpler Word Perfect, later supplanted itself by simpler Word (after Word Perfect had grown more complex), and now Word is really complex – tens of toolbars, including one for editing 3D graphics]. But simple does not imply intuitive (see “Hay Net” example above). UX Fail, again and again.

Different Kinds of People

  • Key point: Intuitive is personal – maybe it works for me, not for you — it is unlikely that all possible users have identical knowledge
  • Prior experience of the user matters – where are the on the Knowledge Continuum?

What is this Knowledge Continuum you speak of? Imagine a continuum where the left-most end is “No knowledge” and the right-most end is “Full knowledge” and your UI is designed for users somewhere on that continuum. If the user’s current level of knowledge is less than the level to which you target your design, your software has a problem – there is a gap that needs to be overcome.

A design is intuitive if the Current Level of Knowledge = Target Level of Knowledge, or if the gap is small enough such that it can be bridged with good UI design. If the gap is too large, you may need training (whether online on in-person).

Two types of Knowledge

  • Tool Knowledge (for a specific tool – Word, Visual Studio, TurboTax)
  • Domain Knowledge (independent of this (or any specific) tool – writing, developing in C#, creating personal tax return with weak tax-code depth)

Techniques for Creating Intuitive Designs

  • Field Studies (watch your users in action)
  • Usability Studies
  • Personas
  • Patterns (reuse known good patterns)

Specific Examples for Creating Intuitive Designs

  • Bring Target closer to Current w/o resorting to training or help. This means your software needs to target the right knowledge level – find that target using the techniques listed above – remember: Developer/Designer does not have same knowledge level as User (at least mostly true).
  • Wizards can reduce target knowledge requirements (bridging that knowledge gap).
  • If your user base consists of very different Current Knowledge levels (e.g., home tax preparation vs. professional tax preparers) you can create two (or more?) specialized/targeted applications.
  • Every six weeks, every member of design team needs to watch users using the design for two hours.
  • Don’t hire an agency to design your experience. (Spool thought it was fine to have an agency implement your application, but you need to design it first if you want to be successful.)

Further Information

Here is an older article by Jared Spool on the same topic as this talk: (thanks Joan).

UIE Resources