The iSchool's Master of Science in Information Management (MSIM) program was designed for Alyson Le'au. Or at least people like her. But she had no idea that the program would pay dividends in her first quarter.

As a senior operations analyst in a reverse mortgages department for Bank of America, Le'au makes sure the information systems her colleagues use to conduct business and assure compliance are doing what they need to do to keep everyone on track.

"I manage all the defects for the origination systems loan officers use," she says. She manages workflow and bug tracking, but also expectations. "If a loan officer is with a borrower and something won't print, that's urgent. If the system goes down, that's also urgent. Everybody's issue is their urgent issue of the moment." Given the workflow, it's difficult for Le'au to even assign tasks a priority when everyone's needs are immediate.

"The creative part is finding the work-arounds people can use to continue moving forward." By identifying the origin of the problem - is it user error, a mistake in the form, or a system defect? - Le'au is expected to provide the backend programmers the information they need to fix defects in the next upgrade.

"Mondays after a code push are always the worst days," Le'au says. In the past she's drawn on the creativity she nurtured as an artist and art student and some native ingenuity to work her way through.

"Usually if there's a weird way [the system] broke then there's a weird way you can fix it."

Le'au joined the MSIM program in autumn quarter of 2010. Her time in class has directly impacted her work.

"In my class on database concepts, I learned to design and build a database to track [system] defects," she says. "The reading from Michael Buckland on intelligent organizations for my 501 class [Algorithmic Thinking] was particularly helpful.

"I didn't know that there were so many people looking at ways to fix the issues I was working on," she says. She also brought the discussions she began in class to her workplace, becoming an evangelist for sound usability practices and the type of design thinking she learned with professor Batya Friedman.

"In the classes we talked about the role of the designer. At work, we have no designers. We have process designers, who are more concerned with workflow than usability. There have never been any usability tests, and the reverse mortgage departments have struggled with this."

"A lot of the issues I see in a day are not system defects, they are usability issues." Knowing what type of problem it was helped Le'au identify solutions. "By getting [defects] routed as a singular group, we can identify trends in what would be good improvements to make in a system."

During the academic quarter, a crisis arose that allowed her to apply what she was studying to a specific challenge. A defect one Monday after a code push resulted in brokers not being credited for their loan origination fees. By the time the programmers were able to respond, the bank had lost six figures in fees they would have to pay but for which they could not charge borrowers.

This got the V.P. for technology's attention. In investigating the problem, Le'au was able to share some of the issues she noted with the defect tracking and resolution process. She also described to Alan what she had been learning about contextual inquiry, a usability practice in which designers observe users with the tools in their native work environment. Le'au gave him an overview of how he should be observing. Together they scheduled his visit.

"Alan told me which departments he wanted to observe. I wrote about this in one of our weekly assignments and Batya let us use class time to refine my plan and make suggestions for his visit.

"My classmates had a ton of suggestions. They suggested debriefing sessions following interviews with the users, and those sessions turned out to be critically important. They helped him get all of his questions answered and also naturally led to brainstorming."

"The visit was very positive. He'd never seen anyone use the system in the way it was intended to be used. I found workarounds that team members never shared with me.

"We saw a lot of things that weren't working right, and proposed possible solutions and made a lot of easier fixes that weren't necessarily programmatic." The result was a low-impact process for identifying needed fixes and making more efficient use of developers' time.

"Alan has been implementing fixes all over the place since he's been back, which has been good," Le'au says. And communication between the users and programmers is less contentious.

"Nobody wants to build something that doesn't work. People want a better way to do things. If you make suggestions that sound good, people will take you up on it.

"And it helped a ton to be able to say, 'I'm actually studying this in school right now.'"