No Time to Waste

It took three projects for me to finally “get it” – In a professional setting, everyone’s time is at a premium, so it’s essential to learn how to most effectively get things done, which includes making a decision when further exploration will likely yield only marginal benefits.

This is different from my previous training, in which exhaustive research was essential in conducting literature reviews for publications, even though academics are also time-constrained. The consequence of missing an important publication in reviewing the literature could be detrimental.

I shall shed my insecurity about not being exhaustive in finding pertinent research. Research in the design process is different.

There is also the issue of how teammates perceive the research one finds. While some might welcome the efforts of finding related research to the project, others might find it overwhelming or unnecessary. Regardless, everyone could use as much processing or digestion of the found research as possible, so that the shared content is greatly condensed and easily usable.

It’s also critical to learn how to get points crossed effectively, whether it’s in team meetings, presentations, or any other situations. It takes a lot of practice to do it well, but every communication can be an opportunity for practice.The underpinning of this “no time to waste” mentality is respect for others’ time. People have their things to do. By completing tasks that need to be done effectively, precious time can be freed up for other things important to them.*The news from my best American friend Lesley about her father’s unexpected death gives another layer of meaning to this “no time to waste” theme of my reflection for this week. Life is short and could end at any moment with no advance notice. Living a meaningful life and cherishing the time with loved ones are what I care about. There is no point wasting time on trivial things.

Design Rationale

Seven weeks into the semester, things seem to start to come together. For example, in Tarun's short talk Thursday evening, he explained eloquently the need for rigorous rationale and how to present it, part of which echoed Hamid's urging of working on the readings for the Foundations course so that we can "speak the language." It's also reminiscent of some of the things Eric has repeated in the "Design Theory" class. When related concepts are approached from different angles or in different ways, the core of them speaks to me. This is another nice thing about the program.

Yes, And ...

Being hung up on our “precious ideas” is so natural that it takes deliberate efforts to let go, be open to alternative ones and try to build on them. It’s interesting observing myself in a group setting and asking “what’s going on inside?” Sometimes it takes time to process feelings, but I’m sure over time I’ll be more in touch with my inner world. I’m glad about learning more about myself and learning to work with different people. This is the real deal (or getting close to it). I wouldn’t want to go into the real world without experiencing these.

It’s also easy to care more about the end product than about the process, but come to think of it, it makes much better sense learning how to fish – even though it takes time – than having a big fish now. I like reminding myself “What’s the worst that could happen?” because it’s true that this is the environment where mistakes or imperfections are least consequential.

Being pulled out of the team in which I spent half of the project time with and being thrown into a different team is a good way to practice both letting go of ideas and learning to care about the process more than the outcome. It’s interesting to see that my new team’s design idea is quite close to one of the ideas I’ve got. So, my original idea is not that “original” or “precious” after all.

Design Research, Being Wrong, Sketching, & Personas

IF our design does not appear to have significant difference compared to other teams’ designs, does it negate the value of the research we did? Should we conclude we would have been better off had we done just the “right” amount of research so that we can show “we have research to back it up” after we’ve shaped our design ideas?

In what ways can a design set itself apart when it’s based on “really good research?”

What does “really good design research” mean?

How might we have done it differently so that the research would have been more helpful?

What’s the value of design research?

*

“I know it’s going to be wrong, but I’ll learn.” Eric said this in the 9/22 class. I like it. Anyhow, it’s quite likely when I’m doing something I know is going to be wrong, or when I try to do something right, I’m likely to drive some people nuts. C’est la vie. If affected, you can always propose to stop me.

*

Denique noticed my way of sketching iterations Thursday night. She not only voluntarily showed me how to sketch them, but also patiently explained the reason behind it and addressed all my reservations/resistance effectively. I had watched the Buxton Stanford video and read his book, but still didn’t get it. Denique used the example I was working on and contrasted my way of sketching versus a better way. Combining this with what I had just learned from Joel and Jeff, I was able to break some of my bad habits and insecurity about sketching almost right after Denique’s illuminating instruction. I can’t thank you all enough! Believe it or not, I’ve found pleasure in sketching even though I just started.

*

Jeff Mahacek’s talk on 9/22 took persona development to a level I had not known. It’s quite interesting.

Alan Klement contrasts personas with “jobs to be done” and “characters.” Klement’s ideas seem more applicable in thinking through which design features to include, whereas personas always seem more distant and artificial in such applications, no matter how “real” they may seem in just looking at them. Perhaps, like Gopi said to me yesterday in another context (and I think Marty said the same thing, too), the key is to learn when to use what tool. I can see the use of personas to invoke empathy. The question is: can Klement’s method do both? Since personas are required in the assignment, I guess for now I’ll incorporate Klement’s idea into persona developments.

Go Deeper

Together, our team spent hundreds of hours on project 2, and we feel we really thought through lots of things via exploration of many ideas and free exchange of questions and rethinking. Looking back, I feel we had a healthy team dynamic, and our approach struck a good balance between creativity and analysis.

If I had to self-critique our process doing the project, I’d say we probably could have started sketching earlier. We did lots of research before we started the ideation process. The number of relevant empirical studies we found was more than forty, which was probably excessive, even though we ended up reviewing only part of them. This excessiveness was mostly my fault as I was still having a hard time shaking off the research mind-set, but design and research are two related but distinct activities. I need to learn how to use research for design in a more effective way.

Additionally, the documentation process could have started earlier so that we would have had much less to do for the final write-up and we would have had more time to plan our presentation. It seems to me that another benefit of starting the documentation process early on is forcing us to think hard on the story behind the design, which could help fine-tune our design or identify the “holes” in our rationale.

Users in the three usability tests we conducted for project 2 had quite different mental models about password management programs in general, and impressions about our prototypes in particular. We went through a major redesign following the 2nd usability test we did based on the user’s extensive feedback, which really helped us see what we had not been able to see.

Our 3rd user was an IT expert who had used password management programs for years. It’s interesting to see that our redesign based on the 2nd user who was much less sophisticated in IT skills and knowledge also seemed to benefit the 3rd user. This leaves me wonder had we switched the users for our 2nd and 3rd tests, what would have happened, and more generally how to select users if we are doing multiple usability tests for a project.

Overall, I’m glad we are continuing working on the project to “go deeper.” Having heard critique for our and others’ project & presentations, we now have fresh eyes again to look at our project. It’ll be a great heuristic experience.

Meetings

It’s about 9:30 pm, more than 12 hours after I stepped into the studio. Our team was preparing for our first usability test.

Lulu and Roy walked into the fishbowl where we were working. They asked questions about how we had approached the project and listened to us patiently. After a while, realizing we were too fatigued to speak coherently, they asked “how long have you been here?” They shook their heads upon hearing our answers, and said “it’s not good” and “no company would allow meetings this long.”

They are right. Even though we explained we were not “meeting” per se the whole time we were there, there could more productive ways to collaborate than working in the same room for 12 hours or even longer.

It’s helpful hearing their reminders that meetings are for decision-making, that we need to be clear about the purpose of each meeting, and that we need to keep a record of the decisions we’ve made, which should be tied closely to our core strategy.

These reminders seem self-evident, but in a group setting, they can easily be forgotten or ignored. Lulu’s suggestion to stand up when the meeting starts to get long-winded is great for speeding up the pace (and it’s much more healthful.)

Additionally, it just hit me a few days ago that “embracing your constraints” can include setting time limits to meetings as well, which reminded me the meetings I had before.
When I was working full-time, I witnessed a wide range of meetings in terms of their productivity and effectiveness. Most memorable is the style in which my supervisor from my first job chaired meetings. As the executive manager of the opposition party’s campaign in Taiwan’s first presidential election, he had lots of decisions to make and different parties to coordinate. There was no time for long chitchat or endless arguments during meetings. My job as his assistant was preparing the agenda and keeping minutes for each meeting, so that every one coming to the meeting had a clear idea about the decision items to be discussed, and everyone knew exactly what to do after the meeting. During meetings, he would encourage everyone to express their views succinctly, ask questions to probe the differences among them, and try to find a common ground. By the end of the meeting, he made decisions that had to be made.

I have reservations about the extent to which this model is applicable to our group meetings, even though design and political campaign management seem to share significant similarities. For one thing, the campaign organization was hierarchical, in which the executive manager clearly had the authority and responsibility for decision-making. For another, our team has spent lots of time together to develop ideas and sketch. It’s been very helpful having teammates to bounce ideas with, critiquing each others’ ideas, asking questions and getting answers from different considerations – and all these activities take time.

For now, I think we can use my former supervisor’s style to help make meetings stay focused and effective, and continue to critique honestly and openly in generating and negating ideas.