So what is a developer experience anyway?

Do you want a sneak peek at some ideas we're working on?

stevencl123456789 — Mon, 23 Jul 2012 17:37:49 GMT

Then please sign up to participate in a user experience study I'll be running from the Edinburgh office next week. On Tuesday 31st July through to Thursday August 2nd, I'm looking for five JavaScript developers who can come in to the Microsoft office in Edinburgh, Scotland to put some prototypes we're working on through their paces.

You'll have to sign an NDA to participate as the prototypes are confidential. It's a great opportunity not only for an early look at some ideas we have, but more importantly for an opportunity to significantly influence the direction we take.

Please let me know if you are interested in participating and I will arrange a suitable time with you.

Upcoming developer events in Edinburgh

stevencl123456789 — Fri, 27 Apr 2012 10:57:36 GMT

There are a couple of great developer events coming up in Edinburgh. Along with my colleagues I've helped to design the user experiences around our Windows 8 and ALM tools. I'll be attending both events and would love to hear your feedback about what we've done in Visual Studio 11.

Windows 8 For Application Developers

Tuesday, May 1st 2012, 9.00 - 17.30

In this event, we’ll deliver developer-level, demo-driven sessions that give you an accelerated entry into what it means to design, develop and publish exciting, modern, polished, world-ready applications for next-generation devices running Windows 8.

https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032507164&amp%3bculture=en-GB

Visual Studio 11 Application Lifecycle Management:

Wed,13^th Jun 2012 9:00-13:00

Microsoft UK invites you to join us at the Microsoft Offices in Edinburgh for an overview of the Application Lifecycle Management capabilities of Visual Studio 11 Beta and Team Foundation Server 11 Beta. This session will demonstrate a slice through an agile iteration starting from our product backlog through development, testing and release.

http://www.microsoft.com/visualstudio/en-gb/visual-studio-events

Free Windows Azure bootcamp in Edinburgh

stevencl123456789 — Tue, 08 Nov 2011 13:45:45 GMT

Sign up now for a free day of training on Azure this Friday 11th November: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496082&Culture=en-GB

Did I mention it's free? You even get a special free pass for an Azure subscription that will let you do the training even if you don't already have an Azure account.

It's free training, with a free Azure subscription. Can't get better than that.

Scott Hanselman demo's the preview tab and solution explorer at DevReach

stevencl123456789 — Tue, 25 Oct 2011 14:49:50 GMT

Scott Hanselman does a demo of the preview tab and solution explorer at DevReach 2011: http://www.youtube.com/watch?feature=youtu.be&v=KVbsNgN4wJg&gl=GB

Start watching around 27:21 if you want to jump quickly to the preview tab and solution explorer stuff. It's an entertaining and incredibly informative talk all the way from start to end though so you might want to watch all of it.

I work on the user experience design for the preview tab and solution explorer and would really love to hear your feedback about this experience.

You can even play around with this yourself. Go to http://www.microsoft.com/download/en/details.aspx?id=27543 to download and install the Visual Studio 11 Developer Preview. You'll then be able to use the preview tab and new solution explorer.

There are some more details about the prevew tab in this post: http://blogs.msdn.com/b/visualstudio/archive/2011/10/07/improving-developer-productivity-with-visual-studio-11-developer-preview.aspx

A Morning With Microsoft

stevencl123456789 — Tue, 06 Sep 2011 11:30:05 GMT

We're running an event in conjunction with Scottish Developers this Friday. A Morning With Microsoft is a chance to learn more about Azure and how we design Visual Studio. Sign up at: http://devmorning-edinburgh-nl.eventbrite.com/

New features for the next release of Visual Studio

stevencl123456789 — Thu, 30 Jun 2011 10:04:15 GMT

One of the new features of Visual Studio that Cameron Skinner demonstrated at Tech Ed recently was the provisional tab. This is a feature that I've been working on for a couple of years so I'm delighted to see it in the product. Some of you might remember taking part in a usability study a few months ago on this very feature. That study helped us understand what we needed to do to deliver a great experience. Thanks to everyone that contributed!

New blog: It will never work in theory

stevencl123456789 — Thu, 30 Jun 2011 09:51:38 GMT

Greg Wilson and Jorge Aranda have started a new blog which aims to be a bridge between researchers who study how software development happens and the practitioners who do software development. Sounds really interesting.

http://www.neverworkintheory.org/

Edinburgh UX book club

stevencl123456789 — Fri, 04 Mar 2011 09:57:24 GMT

Kudos to Ryan Sackett at Precedent for setting up the Edinburgh UX book club. I went along to the first meetup last night and thoroughly enjoyed the discussion. We discussed the book 'Undercover User Experience Design'. It was a great discussion, and it was also great to meet up with other UX folks in Edinburgh. Next time around we'll be discussing 'Simple and Usable Web, Mobile, and Interaction Design (Voices That Matter)' which looks like a great book. If you're in the Edinburgh area, come along.

It's like trying to name your baby

stevencl123456789 — Fri, 04 Mar 2011 09:48:38 GMT

Well, not really, but...one of the things that I remember from a microprocessor technology course I took about twenty years ago while at Uni was the lecturer who said that one of the hardest things about writing C code that targets some little itty bitty 8 bit microprocessor, running remotely on a different board, was naming your functions. At the time my friend and I thought that was hilarious as we battled with compiler settings, linker settings and then all these jumper settings on the board hosting the microprocessor. Yeah, naming our functions was definitely the hardest thing about all that. Of course, many years afterwards I understood his point...

Anyway, this all came to mind when I saw this today: http://www.classnamer.com/. It made me laugh.

Money Dashboard and other amazing developers in Edinburgh

stevencl123456789 — Tue, 18 Jan 2011 11:14:00 GMT

Since I moved back to Edinburgh from Redmond a few years ago, I've been constanly amazed at the number of cool and exciting companies that are based here. I've had the pleasure of visiting a number of them and I've always been impressed by the skills and creativity of each company I've been to. Edinburgh is an exciting place to be for so many reasons.

One such company that I have visited is Money Dashboard. They have a great team of developers and UX people all working on a Silverlight based finance management application. And they are launching soon, so I imagine things will be pretty exciting over there right now...

Climate change and developer personas

stevencl123456789 — Wed, 22 Dec 2010 12:48:22 GMT

I was out on a customer visit a few weeks ago, observing different developers at their workplace as they used Visual Studio to write code and build applications.

One of the developers I observed behaved in ways that were common to both our opportunistic developer persona and the pragmatic developer persona (http://p.einarsen.no/programmer-personality-types-and-why-it-matters-at-all/). For example, he wanted to build up a good understanding of how the different classeshe was working with interacted (very pragmatic) but the approach he took was quite opportunistic (read some code, run it, read some more, follow a reference to some other symbol, make a change, run it, see what happens).

Recently many of my colleagues have told me that they find these workstyle personas confusing. They tell me that in their own observations of developers, they don't see a clean mapping of workstyles to individual developers. Just like the observation I described above, they see developers exhibit some workstyle at some point, and then another workstyle at a different point. My colleagues then question whether or not these workstyles are valid given these observations.

My answer is that it's not unusual to see an individual developer exhibit different workstyles. The workstyle personas are aggregations of common patterns of behaviour we have observed across many developers. We know that most individual developers have a dominant workstyle, but that they may change workstyle based on factors such as the task they are working on and the tools they are working with.

It's like the difference between weather and climate. Here in Scotland we've recently been going through one of the coldest and snowiest Decembers we've had for decades (I love this weather :-) ). Some people have started asking if this means climate change isn't really happening. They point to all the reports saying that the Earth is warming and then point to all the snow outdoors. However, weather is the mix of events that occur each day in the atmosphere, whereas climate is the average weather pattern over many years (http://www.eo.ucar.edu/basics/).

Similarly, the workstyle personas are the patterns of behaviour observed over many developers. Individual observations of developers consist of a mix of events that occur during the observation. Workstyles are to individual developers what climate is to weather.

Usability study in Edinburgh last week

stevencl123456789 — Tue, 14 Dec 2010 11:16:46 GMT

Just wanted to say a big thank you to the developers who came in to the Edinburgh office last week for a sneak peek at some of our ideas for the next version of Visual Studio. Each of you gave us incredibly insightful and useful feedback and it will be used to improve the product enormously. Thanks!

If you want to participate in a study and see what we are doing with Visual Studio before anyone else sees it, let me know.

Blogs are no good

stevencl123456789 — Thu, 14 Oct 2010 10:44:00 GMT

...for understanding who you are designing for.

I've been involved in too many discussions about a design (either after a usability study or a review or during the design process) when we are discussing something that doesn't work or doesn't feel right. Maybe we ran a usability study and observed that nobody could complete a task with the design, or they had a crappy experience. We discuss alternatives to improve the design and sometimes, someone will say 'But we'll get feedback from the blogs that this new design will suck!'.

Are the people who read and respond to your blogs the very same people you are designing for? How would you know? What do you know about who reads and replies to your blog? Contrast that with what you know about who you are designing for. Hopefully a lot more than the user name they use when posting replies to your blog.

That's not to say that feedback you get from any source is not worth paying attention to. On the contrary - it can be very useful to learn about the parts of your product that people are paying attention to or the areas that they feel passionate about. I don't want to suggest that if someone complains about something you shouldn't do anything about it just because you don't know much about the context in which the compaint arises. I know how strong the urge is to deal with negative feedback and how strong the desire is to reach out and try to please everyone that has an opinion of your product.

But your response has to be measured. If you really truly understand your customer, you'll know if the feedback you are getting from a blog posting is consistent with the feedback the person you are designing for would provide. But you can only really achieve such an understanding by interacting with your users, observing them, hanging out at the same places they hang out, doing what they do. You can't expect to understand them from replies you receive to blog posts.

Innovation and design

stevencl123456789 — Thu, 14 Oct 2010 10:25:42 GMT

I just read a great article by Alain Breillat describing the Apple design process: http://www.pragmaticmarketing.com/publications/magazine/6/4/you_cant_innovate_like_apple

There are a couple of things that stood out for me:

A real design process. The article says that Apple designers create 10 different mockups of any new feature they are working on. These are then narrowed down to three options, presumably via design reviews and other processes. These three options are then developed over a longer period of time until one final option emerges as the best realisation of their initial vision.
No market research. I've heard this many times before, especially from people who say to me 'Why do you do what you do, Apple doesn't talk to customers and look at what they produce.' :-). The article does a great job of explaining that even though Apple may not run focus groups, there is no doubt that designers and engineers at Apple know their customers almost better than they know themselves.

Bill Buxton talks about the difference between design and engineering in his book, 'Sketching User Experiences'. Design is all about considering many alternative solutions to a problem and finally agreeing on one that best satisfies the design constraints. It's all about exploring the whole design space and making sure you really are getting the design 'right'. Alain's article suggests that companies need to have a design culture and a visionary leader that enables such a process. I agree that such a culture would be ideal but I don't think you have to wait until such a culture is in place before you can start getting creative. The tools are already there to allow you to create multiple mockups. As designers, we need to recognise that it's our duty to fully explore the design space and that we should avoid the temptation and rush to quickly solve a solution before we've really explored the full design space. We sometimes use the QOC notation in meetings with other designers and engineers to make it explicit that we need to consider other alternatives. I've never had any pushback to this as it is an incredibly useful way of really exploring exactly what we are designing.

I'm also not a fan of simply asking people what they would like us to do. It's up to us to truly understand who we are designing for and what will delight them. As I wrote a few months ago, we need to think of the people we are designing for almost as characters in a movie or a novel. They have characteristics, traits and motivations that, when they are placed in certain situations, cause them to react and to behave in one way or another. We need to understand how they will react when we place them in a situation where they experience our designs. It's the experience we are designing, not the product. How will they react to those experiences, what experiences do they want and need? Again, Bill Buxton does a great job of talking about this in his book.

This isn't easy. Truly understanding the design process and your customer takes a lot of work. But the return on your investment can be huge, both for you and your customer.

There are many ways to skin a cat

stevencl123456789 — Wed, 13 Oct 2010 10:33:36 GMT

I've observed this phenomenon quite a few times in different API usability studies and thought it would be worth discussing.

It's not uncommon for an API to offer multiple ways of accomplishing the same task. For example, the following two lines of code show two different ways of creating a StreamWriter that will append text to a file if it already exists:

System.IO.StreamWriter sw1 = new System.IO.StreamWriter("c:\file.txt", true);

System.IO.StreamWriter sw2 = System.IO.File.AppendText("c:\file.txt");

Quite often, the user isn't always aware of the choices that are available to them. For example, they might choose the constructor approach because it suits the way that they work. Opportunistic programmers for example almost always create instances of objects in code when exploring what that object can do. Or they might choose the static AppendText approach since it reads better (boolean parameters aren't very role expressive). But in this particular example, whatever choice they make won't really affect the user experience they have. In both cases, the user ends up with a StreamWriter.

However, in some cases the impact of choosing to accomplish a task one way as opposed to another can be quite large. For example, I posted a couple of days ago about a problem I was grappling with. If I had chosen one approach, I believe that my application would have become more difficult to maintain as I would be introducing a dependency on the definition of data templates I used in my app. In contrast, the way I ended up solving the problem has fewer dependencies and is likely to be easier to maintain.

Unfortunately it wasn't obvious to me at the time that I faced such a choice. I just wasn't aware of the different ways that I could accomplish this task, let alone the pros and cons of each. I almost ended up prematurely committing to one approach without even knowing it.

We have a natural tendency to latch on to the first possible solution we find to a problem we have. We like the feeling of accomplishment we get when we solve a problem so we work hard towards a solution and the associated rush we feel. Sometimes this works well, but when there are multiple possible solutions, this approach can cut ourselves off from considering each solution.

Bill Buxton talks about this in his book 'Sketching User Experiences'. He talks about the differences between the design process and the engineering process. A design process considers many different designs and the tradeoffs between each, ending up with the 'right' design. The engineering process takes a design and figures out how best to implement it - how to get the design 'right'. He discusses how software engineering projects often consider the design and engineering phase or process as one and the same. As a result, little time is spent considering alternative designs. Typically what happens is the first design is the one that gets built, without much consideration about whether or not that is the right design.

It's a similar phenomenon but on a smaller scale with APIs that have multiple ways of accomplishing the same task. As developers perhaps we need to rethink how we work so that we do a better job of considering all of the alternatives. But changing our behaviour isn't easy. It might be easier to work with APIs that just make it more obvious that there are choices to be made and that help you make the right choice. Brad Abrams blogged about ways to help developers to fall into the 'pit of success'. At a local level, we can use good attractive names for example to orient developers towards the 'best' approach.

On a larger scale though, when the choice is between different approaches, technologies or patterns I'm not sure that there is a simple way to make it clear to developers which approach is right or best. Maybe there isn't even a best approach at this scale? I would be very reluctant to suggest that the APIs should offer fewer patterns for example. The whole point of APIs and frameworks is that they are flexible and can be used to solve many different programming tasks. Reducing the number of alternatives could significantly reduce the flexibility of the API. For example, now that MVVM is becoming more and more mainstream, does that mean we should remove the code-behind model? I don't think so.

There is obviously a role for documentation. I think though that the way that we search for help and documentation could be significantly improved. In my own experience observing developers work, when developers latch onto a particular solution that uses a particular technology or pattern, they refine any subsequent documentation search that they do such that it is related to the chosen pattern or technology. This makes complete sense since it reduces the number of irrelevant results. But the outcome is that they now almost have no chance of being exposed to other solutions. Their searches have gone from being task based (how do I write a line of text to a text file) to technology based (how to I use the StreamWriter constuctor). If there was some documentation search engine that could build up a task context from the sequence of searches that a user has performed, , perhaps that could be used to automatically suggest other alternative techniques.

For example, imagine I do a search for 'accessing a silverlight or wpf templated control'. From the search results I might find something that discusses how to use the method FindName to access a named templated control. My next search might be 'equivalent of findname in silverlight' since FindName doesn't exist in Silverlight. If the search engine assumed that the context of this second search is still the task specific search I did to begin with, perhaps there might be more of an opportunity to offer up better alternative designs, rather than focus more and more on the first solution.

Anyway, these are just some random thoughts I had this morning. If anyone is so inclined, I'd love to hear your thoughts about this.

Interacting with templated controls in a Silverlight based Windows Phone 7 app

stevencl123456789 — Mon, 11 Oct 2010 11:00:00 GMT

I have been struggling all day with trying to figure out how to refer to a templated control in a Windows Phone 7 app. The solution I ended up with was nothing like the solution I spent all day trying to figure out. I wanted to write this up for my own benefit so I might remember this experience.

I have a listbox with the following ItemTemplate

        <ListBox x:Name="QuestionListBox" Grid.Row="1"  ItemsSource="{Binding Questions}">

            <ListBox.ItemTemplate>

                <DataTemplate>

                    <StackPanel Margin="15,0,15,17" Width="432">

                        <TextBlock Text="{Binding Question}" TextWrapping="Wrap" />

                        <ListBox x:Name="OptionsItem" SelectionChanged="ListBox_SelectionChanged" ItemsSource="{Binding Options}" SelectedItem="{Binding SelectedCollectionItem, Mode=TwoWay}" ItemContainerStyle="{StaticResource RadioButtonListItemStyleCorrectAnswer}">

                        </ListBox>

                        <TextBlock x:Name="ExplanationTextBlock" Visibility="Collapsed" Text="{Binding Explanation}" TextWrapping="Wrap" />

                    </StackPanel>

                </DataTemplate>

            </ListBox.ItemTemplate>

        </ListBox>

It shows a series of multiple choice questions and answers. A TextBlock displays the question, then another listbox shows a series of radio buttons (styled listboxitems) to display each possible answer. A collapsed TextBlock contains the explanation for the correct answer. I wanted to reveal the explanation only when the user had chosen one of the answer options (ie, clicked on one of the radio buttons) so I set the Visibility property of this control to Collapsed by default. I had defined a ViewModel for the list of questions so I was binding the content for each of the UI elements to properties of the question ViewModel.

In order to reveal the explanation whenever the user clicked on a radio button I hooked up an event handler on the click event. In the event handler, I could easily access the specific radio button that was clicked, but I couldn't find a way to access the associated explanation TextBlock. The problem seemed to be that since they are templated controls, there was no easy way to access them in the code behind. I searched online for ways to refer to templated controls and came across lots of samples that showed how to get the corresponding ListBoxItem. I thought then I would be able to get the specific TextBlock using the DataTemplate.FindName method, similar to this MSDN page or this blog post.

But I found that DataTemplate.FindName and ItemCollection.CurrentItem aren't available when developing on the Windows Phone 7. So that set me off looking for alternatives. I found quite a few examples: handling the Loaded event for each control, walking the visual tree, or deriving from ListBoxItem and overriding OnApplyTemplate.

These all looked interesting, but there was something about them that just didn't feel right. Walking the visual tree for example seemed to me like that might end up with brittle code that would break as soon as the data template changed. Deriving from ListBoxItem seemed quite a heavyweight solution. Surely there was an easier way.

I ended up spending a lot of time refining my search queries, over time going from the incredibly specific ("accessing templated controls silverlight Windows Phone 7") to the far less specific ("databinding templates"). At some point, I came across something that described ValueConverters. Up until that point I hadn't considered my problem as one of converting a value of one type into a value of another. So I never thought of searching for something like this. But when I read about the ValueConverter that sparked another thought process.

Ten minutes later I had accomplished the task. I defined an enum to record the 'answered state' of each question, then added another property to the question ViewModel to record whether or not the question had been answered. Then I bound the Visibility property of the explanation TextBlock to this new property and used a ValueConverter to convert from the enum to the Visibility property of the control.

    public enum QuestionAnswer

    {

        Unanswered,

        Correct,

        Wrong,

    }

<TextBlock x:Name="ExplanationTextBlock" Visibility="{Binding QuestionAnswered, Mode=TwoWay, Converter={StaticResource visibilityConverter}}" Text="{Binding Explanation}" TextWrapping="Wrap" />

    public class VisibilityConverter : IValueConverter

    {

        #region IValueConverter Members



        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

        {

            if (parameter == null)

            {

                QuestionAnswer qa = (QuestionAnswer)value;

                return (qa == QuestionAnswer.Unanswered) ? Visibility.Collapsed: Visibility.Visible;

            }

            return false;

        }



        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

        {

            throw new NotImplementedException();

        }



        #endregion

    }

It seemed a lot simpler and a lot cleaner to me. Of course, it's still entirely possible that I have completely overlooked a much simpler way to do this but after a day of trying to figure it out, this feels good enough to me.

Bricolage, tinkering and gender differences in programming

stevencl123456789 — Mon, 04 Oct 2010 14:49:23 GMT

There's a great essay at http://online.wsj.com/article/SB10001424052748703989304575503730101860838.html describing how great ideas often don't come from "momentous ideas transcending their surroundings, a gifted mind somehow seeing over the detritus of old ideas and ossified tradition". Instead, many great ideas come from a process of tinkering with the materials or ideas at hand and combining them in interesting and novel ways.

We often describe our opportunistic developer persona in this way (see http://p.einarsen.no/programmer-personality-types-and-why-it-matters-at-all/). The opportunistic developer is one who excels at taking existing code and components and combining them in some way to accomplish a task. They don't invent brand new solutions, classes or frameworks. Instead, they stitch together existing components in creative ways to solve their task.

Sherry Turkle and Seymour Papert wrote about something similar when they observed female students be more succesful at programming tasks when they could build their program by modifying a working program bit by bit, 'sculpting' a solution together (http://www.papert.org/articles/EpistemologicalPluralism.html). Turkle and Papert refer to this as bricolage.

The good folks at Stanford have done a ton of great research on opportunistic programmers (http://hci.stanford.edu/research/opportunistic/). They have come up with tools to enable this kind of bricolage or tinkering approach to programming.

This is all very good work, but there is potentially some social bias in the terms used. Both bricolage and tinkering are very much associated with males. Think of the man tinkering away on an old engine in the garage or garden shed. Alan Blackwell and colleagues point out that in informal French, bricolage is a synonym for a DIY enthusiast (http://www.cl.cam.ac.uk/~afb21/publications/Bricolage.pdf), which is a hobby predominated by males. In their paper, Alan Blackwell and co. demonstrate the differences that exist between males and females in terms of their confidence in being able to complete a given programming task. An ex colleague of mine, Laura Beckwith, also made very similar observations in her PhD (http://academic.research.microsoft.com/Paper/2420968.aspx?viewType=1)

According to Alan Blackwell's paper and Laura's work, if we think of succesful programming practices in terms of bricolage or tinkering, it's possible that the inherent social biases will still make females feel less confident that they could complete a given task, since it's seen as very male oriented. This could prevent us from coming up with models of programming that will benefit both genders. Alan Blackwell's paper proposes an interesting idea which I haven't really seen being taken up. Read the paper and let me know what you think.

Edinburgh Windows Azure Briefing

stevencl123456789 — Fri, 01 Oct 2010 11:54:52 GMT

We're holding an event on Windows Azure on October 12th in the Edinburgh office.

Full details and signup info is here.

Windows Phone 7 Developer Event

stevencl123456789 — Fri, 01 Oct 2010 11:50:25 GMT

Gergely did a great job last night demonstrating how to build applications for the Windows Phone 7 device. He has put his slides here.

If you attended and have any comments you would like to share about the event, please drop me a note.

Anyone interested in a Windows Phone 7 developer event in Edinburgh?

stevencl123456789 — Wed, 25 Aug 2010 12:32:13 GMT

We're thinking of holding a Windows Phone 7 developer event in the Edinburgh office. Something like an introductory tutorial on developing apps for Windows Phone 7.

At the moment we're trying to estimate the level of interest. Let me know if you would be interested in attending. It would maybe be a half day event, some time towards the end of September.

How can you make a better measuring cup?

stevencl123456789 — Tue, 24 Aug 2010 10:11:07 GMT

Nobody complains about how measuring cups work. But the OXO measuring cup was designed after careful observation had identified a problem that nobody had really ever noticed before.

It's well worth watching this video for more details about the product development process at OXO: http://goodexperience.com/2010/08/a-product-development.php.

I haven't seen a better demonstration recently of identifying unmet needs through careful observation. The presenter, Alex Lee, plays down the skill and depth of insight required in being able to observe people doing very common and familiar tasks and identifying the breakdowns that occur. It's difficult because as observers, we are so familiar with the activities we are observing that we take the same things for granted that the people we are observing do. Great observers work hard at stepping out of their comfort zone so that they can observe from a completely different perspective, always asking 'Why is it like that?'.

One of the techniques I try to use in these situations is the master-apprentice technique from Contextual Inquiry (http://en.wikipedia.org/wiki/Contextual_inquiry). In it, the observer acts like an apprentice, learning from a master (the person being observed). It helps me drop any biases or preconceived ideas I might have about the activity I am observing since it reminds me that I am learning from the master and that there are many things about the way the master does their work that I don't know anything about.

Making effective use of personas in design

stevencl123456789 — Thu, 19 Aug 2010 15:08:05 GMT

I've created and worked with a number of different personas during my time in the Visual Studio User Experience team at Microsoft. I've learned a lot about how to use them effectively, and, contrary to what others have recently written about the use of personas, I believe they are still indispensable in product design, when used effectively.

Before I get on to how to use personas effectively, let me describe why I think they are indispensable.

A persona is a character in a story. The story involves the character using a product in a particular context, to achieve some goal. A believable and well designed persona is like a well developed character in a novel. They have beliefs, motivations, work styles and characteristics that explain their behaviour in a specific scenario. Given a scenario, the behaviour of a well developed character in that scenario can be explained by describing the way that their motivations, traits and workstyles influence the choice of actions that the character takes.

As designers, we are writing a story in which our personas are the main protagonists, a story which does not yet exist. We want the outcome of the story to be one in which the protagonist has a great experience achieving some goal or task. We have the power to shape the story through the design choices we make. Our intent is to maximise the potential for the protagonist to be successful and for the experience to be a great one. The way we achieve that is to imagine the different situations that our protagonist finds themselves in, in which they grapple with whatever we have designed in pursuit of their goal. We use our understanding of their motivations, desires etc to determine how they behave in those situations, using whatever we have designed for them.

It's this ability to place the persona in a scenario that had never before been imagined and determine how that persona will likely behave that makes them indispensable. But wait a minute, isn't that what usability studies are for? And those don't require use of your own imagination - they involve real people. Why can't we just ask a real person instead of a substitute for a real person? Well, as UX Myth #21 points out, what people say they will do isn't always what they really will do. You can't rely on being able to ask someone how they will behave in an imaginary situation. They have to be placed in that situation to really see how they will behave.

The crucial point is that we're doing this very early in the design process, before anything has been built. So we can't run a usability study since we don't have a prototype, storyboard or mockup, let alone a working product to study. It's the part of the design process in which we are figuring out what we should be doing.

Think about that moment just before you put pen to paper when sketching a design. How do you know what to sketch? If you rely on your customers telling you what to build, you run the risk of building something they don't really want. A well designed persona informs design, helping you determine what you should be designing, as opposed to how to design it.

A great example of this is one of the personas I worked on with the VS Test team a few years ago. We developed a persona named Ellen, the vigilant tester, to better understand the workstyles and motivations of testers. As David describes, the persona helped us understand that we needed to design a completely new product for manual testers.

It's very unlikely that we could have run a usability study or a focus group for example, to reach the same conclusion so confidently. We needed a rich and deep understanding of what makes testers tick to be able to determine what we needed to design. The persona represented that rich and deep understanding. It allowed us to imagine how testers would react if we gave them a product that was radically different to Visual Studio.

Of course, we needed to fully understand that persona, embrace it and know how to place that persona in a particular context and accurately determine how the persona behaves. This is critical to being able to use personas effectively. It's not enough just to know the persona's name. You have to know them and understand them so well that you could place yourselves in their shoes and behave as if you were them.

Now, how do we use personas effectively?

It really comes down to how well the persona is described and understood. The focus of the description should be on the motivations, traits, workstyles and characteristics of the persona. Not on things such as how many pets the persona has and what their favourite colour is. I've seen some persona descriptions that contain too much trivia. They don't present convincing characters at all and simply can't be used to imagine how that person will behave in a specific scenario. For example, Josh Ledgard presents a caricature of one of the developer personas:

Meet Mort. He’s 50 years old and he is a rocket scientist. He’s been married twice with 4 children. One of the things he does as part of his job is develop applications that connect to embedded devices used to test missile guidance system. He doesn’t have the time to learn the ins and outs of programming languages so he relies heavily on visual tools and code completion services in the editor to help him write.

Such descriptions are easy to write since they are pretty much void of meaningful content. Getting to the point where you can create a rich and meaningful description of a persona isn't easy. It needs a lot of work, observing people and learning about their needs, desires, motivations. As we've discussed before, it's not that easy just to talk to people to learn these things. You need to observe them in the types of scenarios you are designing for.

In the case of the Ellen persona I mentioned before, we spent a lot of time observing testers doing their jobs. We noted all the things they did, when they did them, the way they did them. We used those observations to describe their motivations. For example, it was clear to us from our observations that testers absolutely thrive on finding bugs, not on running test cases. If they don't find any bugs they feel like they aren't doing their job properly. They know bugs exist, the motivation is to find them. They are driven this way since their ultimate goal is to ship a product that delivers a flawless experience to it's end users.

Nobody ever said to us that they enjoy the thrill of chasing down bugs in a product. But you could see from the way that they behaved that this was the case. From other observations we built up a profile of the persona consisting of the motivations, traits, workstyles and characteristics of the testers we had observed.

Having created the description, we soaked it all in. We played thought experiments - 'How would Ellen react to...?' in order to determine if we really understood the persona. We looked for other sources of data that confirmed or refuted the claims we had made in the persona and adjusted the descriptions accordingly. We presented the persona to multiple groups throughout the Developer Division. The more we presented the persona, the better we understood it since people at every presentation brought up new questions about the persona. We created posters, a web page and other presentation materials to communicate the persona. Any time we interacted with a customer we would reflect afterwards on the things that they had done and the things that they had said that were typical of Ellen. We pointed these out to other team members and built up a repertoire of stories to tell that described particular aspects of Ellen. Any time somebody made what we believed to be an incorrect assumption about Ellen or about the design, we would step up and debate the assumption with them. As a result, either the description of Ellen was enriched with some additional insight or the person we debated with ended up with a richer understanding of the persona. In short, once the persona was created, that was only the beginning. We continued to develop the persona and the way that we described and presented the persona.

Such descriptions on their own though aren't sufficient for making good design decisions. You need something that will help you drive the design in the right direction. The next step is to take these motivations and create a set of design principles (Sam Moreau has a great PDC presentation on how design principles shaped the design of Windows 7: http://channel9.msdn.com/pdc2008/PC22/).

The design principles shape the direction of the design. They help you determine what you need to design and if what you are designing is the right thing to design.

One of the principles that came out of the tester persona was to optimise the design for finding bugs. Experiences, features and designs that resulted in the maximum amount of time being spent finding bugs would likely make testers happy since we knew this would resonate with their underlying motivations. This, and other design principles were used constantly throughout the lifecycle of the product to determine what we should be designing and building.

Neither the personas or design principles told us that we needed to design a page based UI containing various activity centres for the different tasks that the tester finds themselves doing. The decision to create these specific designs though was driven by the principle of maximising Ellen's time on fixing bugs. Each time we made a decision we would always ask ourselves if it felt like the right thing to do for Ellen.

Of course, as design progresses you'll use other techniques to iterate over your design and get it right. You'll follow the appropriate design guidelines to make sure that whatever you are designing, you design it right. You'll run usability studies to get more detailed answers to specific design questions you have, once you have a design direction. You'll use beta releases to get feedback from a large portion of your customers etc. Personas are but one of the many tools you use in a development project.

But even though you may use other tools and techniques as you progress through the project lifecycle, the persona should be influencing everything you do in some way throughout the project. The persona is the thing that helps everyone on the team empathise with their customer and is what drives change. By embracing and understanding the persona, you are driven to make things better for that persona.

To summarize:

Personas are indispensable during design because we can't rely on being able to ask people what they would do in a particular scenario.
Great personas are personas that describe workstyles, characteristics, traits and desires. Bad personas are personas that focus on trivia such as favourite colour.
Use personas to provoke design discussions, not as a checklist of features to create.
Create design principles from the description of the persona and use these to drive the design.

A language for parallel programmability

stevencl123456789 — Wed, 18 Aug 2010 15:09:23 GMT

Parallel programming is difficult. No surprises there really. I came across a great slide deck discussing some of the issues in detail. A portion of the deck does a great job of using the Cognitive Dimensions framework to analyse various language constructs. Well worth looking at.

Searching and skimming code

stevencl123456789 — Mon, 09 Aug 2010 11:39:28 GMT

Came across an interesting paper today: http://www.chrisluce.com/doc/icsm2009.pdf

It describes a study in which 10 developers were asked to fix two bugs in a software system they had no experience with. The system consisted of 70 thousand lines of code. The paper describes how the participants used search to orient themselves to the code. There are five key observations:

Participants first formed hypotheses about what the problem is based on their past experience. These initial hypotheses were often correct and guided much of their work on the task.
From their hypothesis, participants formed search queries based on experience and expectations around naming conventions. Sometimes trying multiple searches based on synonyms or various ways to express similar ideas.
Participants often had only a fuzzy notion of what to search for (or what to look for in a result set) especially early in a task. Often their searches were very general and returned many results.
Rather than systematically investigate search results, our participants generally skimmed through results looking for evidence of relevance (based on their hypotheses), at times focusing on a package that was consistent with their guiding hypothesis.
Participants opened a small number of results in the source code editor and rarely return to their search results (i.e.,not iterating between results and elements). Most often the opened element was only skimmed.

The most interesting observation for me though was the ineffectiveness of search as a means to orient yourself to an unfamiliar code base. Of the 96 search episodes observed across all 10 participants, only 5 search episodes resulted in highly relevant items being returned and subsequently opened by the participant in the editor. There were many more episodes in which highly relevant items were returned by the search performed but these weren't noticed or recognized by the participants and were not opened. In some cases, these highly relevant items weren't noticed because they were buried in thousands of other search results.

The paper suggests that there are opportunities for tools to increase the effectiveness of search by providing better support for skimming search results. Making more contextual information available for example would help. Others have also suggested that foraging through source code would be better supported by the use of information scent on search results so that developers can see where they are most likely to find something useful.

Do developers have culture?

stevencl123456789 — Wed, 21 Jul 2010 13:10:00 GMT

There are many descriptions of how developers work, think and act. For a long time, we've distinguished between opportunistic, pragmatic and systematic programmers (there is an old and short description of these here: http://blogs.msdn.com/b/brada/archive/2003/11/18/50737.aspx). A more up to date description is here: http://drops.dagstuhl.de/opus/volltexte/2007/1080/

Researchers at the Stanford HCI Group have seen similar workstyles and have focused a lot of effort to better understand opportunistic programers: http://hci.stanford.edu/research/opportunistic/

Most recently, Andy Ko just posted a great blog post on a specific developer culture: http://andyjko.com/2010/07/13/mozilla-summit-2010-and-dev-culture/. It's well worth a read.