Catherine Powell specialises in QA, to ensure software works well, but also thinks about what makes the workplace work well: being nice. Have a look at Catherine’s blog about her professional attitude of choice.
Design can change the culture
I was reading a comment by Creative Sage CIO and CEO, Cathryn Hrudicka, about corporations that want to use social media to reach their market:
The process of trying to become a more “transparent” organization, so they can use social media tools, pushes many organizations—companies, nonprofits, trade associations—into change, especially if they have had a very bureaucratic and non-transparent culture before. That can mean many levels of changes, which usually bring up issues between executives or managers and their teams, and it can affect relationships between staff or team members. Individuals often need to be coached to adapt to the new practices or even to drive them more effectively. Some leadership and teamwork issues come up, too.
It reminded me of a company that changed after I was asked to introduce an ideation-design method. The management team wanted the method to do double duty—a way to empower and encourage the development team.
Prior to this, it seemed team members had been discouraged from taking design initiative. Half the team was disheartened or miserable, the other half of the team was disengaged to the point where they wouldn’t offer a design suggestion even when asked by their boss. Initially, some team members took a wait-and-see approach, but after training and several successful project experiences, the majority of developers became increasingly comfortable with involvement in product design.
It took commitment from key managers to invigorate the team, and it took considerable time. They still use Five Sketches™ today.
If you liked this post, check out a recent post about Google’s corporate culture.
Design and engineering culture
I’m sure Douglas Bowman’s blog last week was widely read. His post was a kind of public exit interview, titled Goodbye Google.
As Bowman left Google, he pointed out the pro-engineering bias in its approach to problem solving—including problems of design. Two of several examples he gives:
[…] a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. […]
Bowman would like to see more weight put on design principles. His blog includes a link to Wikipedia’s article on design elements and principles, which lists:
| • | unity | • | harmony | • | contrast |
| • | balance | • | repetition, rhythm, pattern | • | variety, alternation |
| • | emphasis, dominance, focal point | • | proportion, scale | • | functionality |
| • | attraction | • | artistic unity | • | genuineness in media and form |
| • | proximity | • | colour |
I don’t think design principles are beyond an engineer. I do think engineers need to be taught how—and when—to think about these details.
As we discovered during the development of Five Sketches™, this kind of detail is often outside the comfort zone of an engineer. However, I can affirm that even engineers who initially produce work with little design insight or creativity have managed to astonish me with amazing design results within a year. And that’s after only occasional participation in Five Sketches™ design sessions.
So, yes, engineers can learn to participate in design, with success and predictability, though I would caution that Five Sketches™ works for engineers because it was developed for and with them, to meet their needs.
At Google, to bring about such a cultural change, Bowman would have needed the unwavering support of at least one senior executive. Even then, as Bowman himself acknowledged in his goodbye message, a company as large as Google does not change direction easily.
If you liked this post, read about how a company’s use of social media influences its corporate culture.
Why products stay pre-chasm
I’ve spent some time working with legacy products—software for which the core code was written before “usability” was a term developers had heard of, back when developers were still called programmers.
I remember my first conversation—held last century—with a developer about his users and the usability of his legacy product. 
I used Geoffrey Moore’s book, Crossing the chasm, to introduce the idea that there are different types of users. The chasm (illustrated) shows five groups of users. The area under the curve represents the quantity of potential users, in the order in which they will typically adopt the product. Users who are technology enthusiasts and visionaries either enjoy or don’t mind being on the bleeding edge because of the benefits they get from using the product, according to Moore. Usability isn’t one of the typical benefits to the left of the chasm, where new products are first introduced. Wider adoption follows only after the product is made to cross the chasm—but this takes a concerted effort on the part of the development team.
What delays a product from crossing the chasm?
- Revenues that are sufficient to let the company putter along.
- Team members who themselves are tech enthusiasts or visionaries. This occurs, for example, when a nutritionist who also knows how to program develops software for nutritionists.
- Team members who have infrequent exposure to newer user experiences. This could include someone who still uses Microsoft Office 2003, eschews social-networking applications on the web, or uses Linux.
- Product managers whose roles are weakly defined or absent, making it more likely that new features get developed for the technical challenge of it, rather than for the user need or the business strategy.
- Sales reps who ask for more functions in the product in order to make a sale—and a development culture that goes along with this.
- Managers whose vision and strategic plan leave out user experience and usability.
- Team members who have been on the team for decades.
- Organisations that don’t use business cases to help them decide where to apply business resources.
- Organisations with poor change-management practices—because moving a product across the chasm is more likely dramatic and disruptive than smooth and gradual.
- Designers who are weak or absent in the process, so that “design” happens on the fly, during development.
If you recognise your work environment or yourself in this list, do you want to change things? If you do, but don’t know how, what actions can you take to learn the answer?