Design and the Installer
By Nalini Kotamraju on Dec 17, 2007
Nalini Kotamraju is a user researcher in xDesign, and holds a Ph.D. in Sociology. She has a penchant for research methods and telling it exactly like it is.
Anant Kartik Mithal, Ph.D. is the Director of xDesign (Software User Experience Design Group) at Sun Microsystems.
I recently spoke with Kartik Mithal, Director of xDesign about the reasons behind the success of the New Solaris Installer.
Nalini: The redesign of the Solaris installer has received wildly positive reviews, both from within Sun and, most important, from our customers. Can you tell me what made the redesign such a success?
Kartik: What was so important in this instance was looking at the complexity of the existing Solaris installation and:
1) Figuring out how to get the team to understand that the designers understand the complexity; and
2) Breaking up the design process into pieces that the engineering team could handle and get on board with.
In other words, you need to earn credibility with the team. The team needs to understand that you know where they’re coming from and the challenges in what they’re currently working with. And you need to figure out the path of least resistance. At the same time, you need to make it something that fits together. The user doesn’t and shouldn’t see the challenge in installation. There’s a lot of planning to make it that way for the user, to plan around the "gotchas."
Nalini: Can you say more about how designers, such as Frank, can get teams to believe that they understand the complexity?
Kartik: So if you sit down and design an installer, often the engineering team looks at the proposal and says "Yeah, we can’t do that. You’re so completely unfamiliar with what we’re grappling with that it’s not useful for us to talk to you." What designers like Frank do is go into the installation process and understand — it does this, it does that, you can do this at this point. You basically build a flowchart and say this is what’s happening now and this is what it’s doing. For example, suppose you want to have a GUI-based install, but you need to have a window manager running in order to get the GUI install to work. The designer needs to know as the installer is chugging along that this is the capacity of an installer at any given point. My understanding is that Frank put together a flowchart that helped him understand the process, and the installation team could look at it and say "He really understands what we’re doing." And that’s the really important part — gaining credibility with the team.
Nalini: You also mentioned the importance of creating a design that can be broken down into pieces that the engineering team can get behind.
Kartik: Yes, for me, the other big thing that Frank did is chunk the project in a meaningful way, working with the team to break it down for implementation and in meaningful chunks.
Nalini: You’ve talked about the importance of the designer’s credibility with the engineering team. What about the engineering team’s role in making this redesign such a success?
Kartik: The biggest thing the team needs is to want to make the usability improvement, and, in this case, the team really wanted to fix it. They could see similar installers – Linux, Windows, Mac – that were much smoother than ours. Frank did a lot of comparative analysis of what’s out there, and he presented it to the team. The team’s role was in accepting the design early on, giving Frank feedback and working with his prototype like bats out of hell and basically implementing in a really short amount of time.
Shortly after Frank had done the prototype, he could point and say this is running code. The team also split things up so that the GUI part was built separately from the infrastructure part. There was a point that Frank would run the GUI, it would say something like "install on this disk," and it would pretend to install. It freed up both pieces so that the people focusing on the GUI could move as fast as they needed and the people working on infrastructure could move as fast as they needed. And they came together when they needed to connect.
Nalini: So xDesign does redesigns quite often. What makes this instance exceptional?
Kartik: What's unique about this situation is the Solaris installer itself; getting Solaris to have a nice graphic bootable boot-up. There are systems that haven't been reviewed for a long time. You make some decisions about what the software can do, and then you layer on more decisions, and then you end up with this gnarly piece of code that is doing a whole bunch of things you want it to and some you don’t, but fixing it means fixing a whole bunch of code. And people don’t want to do that.
We put designers like Frank on this so that they can go and work with the team to pull the whole thing apart and redesign it in a way that solves both the code/architectural problems, as well as the user experience/design problem.
In this instance, the correct answer for the user is really obvious: should I install or not? But we ended up before with an installer that asked lots of questions. It’s easy to conceptualize the answer, but it’s hard to figure out how to get to the answer, figuring out how get from here to there.
That's the thing that I value most in this design. Not the actual design – it’s excellent, of course – but it's getting to the pieces that then fit together that is the rocket science.
Nalini: What would need to be in place to replicate this kind of design success?
Kartik: First, you need a problem with the original amount of gnarliness. We know we have the same problem in some of our software. We were in a situation that we had a bunch of gnarly code, and it would scare people. Everyone knew what the right answer was, but how do we get there? Everyone needs to agree that the problem needs to be solved.
When designers go into work with teams that are not familiar with them, they have to establish credibility at two levels. First, that the designers can design. Frank established this through his prototype. Second, that the designer can understand the problem. In this instance, understanding how the installer worked, documenting, doing competitive analysis and being able to say that other products handle something a different way. Designers go into teams that have been doing that job for many years, and designers need to establish, as quickly as possible, that you have the design chops and the credibility as people who can understand their problem space. Frank was able to do that.