Usability and Usefulness in Software Architecture tools

Welcome - And some thoughts about architecture tool usability

 

My name is Jens Jacobsen, I'm a program manager on the team that creates the architecture tools in Visual Studio Ultimate. Welcome to my blog!

Usability of architecture tools

As a former usability engineer, my main focus in this blog will be on the usability of the Visual Studio Architecture tools. I wanted to start a blog with two purposes:

·         To share with you and hopefully discuss with you some of the designs you see in Beta2 of the product.

·         To learn from you where we went wrong, what we're missing, and what we're doing right. Thus, any comment on the user experience of the Visual Studio Architecture tools are very welcome.

 

Now, what do I mean by usability? One of the earliest and best definitions of the space comes from Ben Schneiderman. He divides usability into 5 areas:

·         Ease of learning

·         High speed of user task performance

·         Subjective user satisfaction

·         Low user error rate

·         User retention over time

 

Let's look at each of them, and what they may mean for architecture tools and ours specifically:

 

Ease of learning

Here I'm thinking about the ability for you or your team to take up and use our tools with a minimum of confusion and productivity loss. Things that we think drive this are:

·         Consistency with the UML standard and typical modeling tool gestures. This obviously helps users transition from other modeling tools

·         Consistency across designers, so that your learning transfers between them.

·         Simplicity. Many users have told us that the complexity of some of the existing modeling tools make it hard for a team of inexperienced modelers to be productive with them. Are we being successful here? In some cases, it seems we are. We're getting good feedback on the Layer designer, for example, that it is very easy for a whole team to take up and use, but we're very curious to have feedback on the general learnability of our designers.

 

Getting it done fast - High speed of user task performance

In some cases, architectural design is a contemplative process, and the time spent actively using the tool is miniscule compared to the thinking time. In those cases the efficiency of the tool is secondary. But more often, when the going is good and the ideas are flowing freely, you want to get them "on paper" as quickly as possible, and then it is important that the tool doesn't get in your way.  A lot of my initial posts are going to be about small tips that makes it a bit quicker to use our tools.

 

Avoiding errors (and saving the day when they occur)

Hah! Gotcha! Sometimes you make a mistake and a tool formerly snickers at you, forcing you to do large amounts of work to get it right again. This can be damaging for a design tool, where you want to stay in your flow and work creatively, knowing that you can change things later. On the other hand we don't want to be flexible to a point of confusing and overwhelming the user.

A lot of the work we've done since we had initial working bits, has been to add more flexibility to the experience, allowing you to explore different paths in your design without paying too high a price. Have we gone far enough? We'd love to hear from you.  

 

The feel good factor - Subjective user satisfaction

I have recently been re-introduced to Legos, and I have to say that it is not hardship at all to join my kids in playing with them. I even find myself sneaking over to the Lego bins when they aren't around! Part of the reason is the very pleasant way that these things snap together. It just makes it that much more enjoyable. (As opposed to building IKEA furniture, maybe?) 

There is definitely a parallel to that in architecture tools. Beyond the utility of the tool, there are other reasons why you might decide to draw a diagram in VS and not on your whiteboard or on paper.  Is it a pleasure to grab a class shape and move it to where you want it? Does relationships snap to their shapes in a good way? Does the output look good? Let us know how you feel.

 

User retention over time

Ideally, as a user, you won't have to learn our tool from scratch every time you take a break for a week or two. Visual cues such as icons, and general consistency tend to improve this aspect, while non-standard UI and poor helper text tend to hurt it.

If you find yourself repeatedly looking for the same thing, then we've failed on this, and I'd love to hear about it!

 

Usefulness of architecture tools

Now, after all this talk about usability, I have to say a few words about usefulness. While I will start out talking mostly about usability, I'm also interested in how the tools fit your needs. Did we miss a key feature to complete your workflow? Do you have new ideas for how modeling tools can be helpful?

 

Yell at me!

So there. Got the philosophy off my chest. Next week, I'll start a series of posts where I talk about small tips and tricks that we hope make our tools easier and more efficient to use.

 

In the meantime, I'd love to hear any comments about your experiences with Beta2 so far, and how the initial learning experience has been. Yelling is OK!

 

Thanks,

--Jens

 

 

 

Published Thursday, November 05, 2009 5:47 PM by Jens Jacobsen

Comments

 

Ooh said:

Hi Jens, congrats to your blog :-)

Question: does the classical Class Designer (which was already available in VS2008) also belong to your team?

Reason: I do have a usability issue with it. Firstly, let me give you some context. The main purpose for creating class diagrams (*.cd) for me is to document the design, usually with the goal to produce a short quick start document for new developers coming to the team. Such a document doesn't touch every single aspect nor does it want to. It's for getting a more detailed view than just a layer or dependency diagram, though not as detailed as a full diagram of all classes that belong to some aspect. Therefore I heavily use the functionality to hide members from the class diagram. Unfortunately, refactoring regularly leads to diagrams with broken layouts. For example, introducing a new field or extracting a method results in the new members being added to the diagram (of course because an exclude filter is applied and these members weren't excluded). My problem is that roughly after 6 months I completely have to recreate the diagram because of this issue.

Can you move to an import filter model? Or, considering other use cases, provide a per-diagram switch between include and exclude filters with a VS-wide default setting? That would really be awesome and make my work much more enjoyable :-)

Kind regards,

Ooh

November 5, 2009 4:43 PM
 

Jens Jacobsen said:

Ooh,

Thanks!

I'm happy to take any feedback you have on the Class deisgner. While my team is not working on it in the 2010 release, we may very well own those scenarios in a future, and in the meantime I'm happy to forward the information.

First of all thank you for sharing the scenario with us. It really helps us understand what you need and why you need it.

It seems you want more control over what gets added to your diagram when it gets updated against the code. From your suggestion of providing the ability to say "don't add anything I haven't explicitly included in my filter", I take that you'd like this to be fairly automatic, once you've set your filter.

A few questions:

Is it only the additions that cause problems for you, or do deletions and other changes cause similar issues? I supect that the layout concern is mostly with additions.

How would you like to go about allowing new things to be included in the diagram? Is this something you would like to choose every time it updates, or something that you'd rather have as an explicit action that was independent of individual updates?

Is it a goal to see what has changed since last time? I know we don't do a good job of that right now, but I'm curious as to how important a feature like that would be to you.

Thanks again for your feedback! I obviously can't promise anything for future releases, but input like this really helps us in understanding what is important to you.

Thanks!

--Jens

November 6, 2009 4:06 PM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker