Integrating Design and Agile Development
If you liked my colleague Alice Toth's presentation on Agile Requirements, you'll like her talk on integrating design and agile development:
AGILE AND ME a story with just enough documentation.
A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements? Here's how we do it at Pathfinder:
Like what you see? Check out more of Pathfinder's presentations, whitepapers and articles here.
The Costs of Building Secure Applications
'Achieving Balance' by James Jordan
Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.
A New President, A New Whitehouse.gov
Change has come to America, and so, too has it come to whitehouse.gov, the official website of the President of the United States.
One minute into the 44th Presidency, the website sports a radically new look (I'd love to hear how that was handled), and all the neccesary updates as a new administration moves in have already been made. But the changes promise to be much more than cosmetic. According to a statement on the White House Blog, Macon Phillips, the Director of New Media for the White House, "Millions of Americans have powered President Obama's journey to the White House, many taking advantage of the internet to play a role in shaping our country's future. WhiteHouse.gov is just the beginning of the new administration's efforts to expand and deepen this online engagement."
Efforts will be made so that whitehouse.gov "puts citizens first" through three main priorities. Again, from the same statement:
"Communication -- Americans are eager for information about the state of the economy, national security and a host of other issues. This site will feature timely and in-depth content meant to keep everyone up-to-date and educated. Check out the briefing room, keep tabs on the blog (RSS feed) and take a moment to sign up for e-mail updates from the President and his administration so you can be sure to know about major announcements and decisions.
Transparency -- President Obama has committed to making his administration the most open and transparent in history, and WhiteHouse.gov will play a major role in delivering on that promise. The President's executive orders and proclamations will be published for everyone to review, and that’s just the beginning of our efforts to provide a window for all Americans into the business of the government. You can also learn about some of the senior leadership in the new administration and about the President’s policy priorities.
Participation -- President Obama started his career as a community organizer on the South Side of Chicago, where he saw firsthand what people can do when they come together for a common cause. Citizen participation will be a priority for the Administration, and the internet will play an important role in that. One significant addition to WhiteHouse.gov reflects a campaign promise from the President: we will publish all non-emergency legislation to the website for five days, and allow the public to review and comment before the President signs it."
Read the full statement
I may have visited whitehouse.gov three or four times in my life, but I'll be back quite a bit after reading this, excited and hopeful about the ways that the new administration will use technology to connect to the people.
Topics: Design, government, Web 2.0
Drupal.org redesign - An Experiment in Design by Community
Drupal, the popular open source Web Content Management System, has got a massive and passionate community of developers, designers and webmasters. Drupal.org, their official website was faltering under the weight of this growing community of diverse users, so this past summer the powers that be at Drupal decided to hire an outside agency to do a complete redesign of the site. The firm they hired decided to take a "design by community" approach to the project. They wanted to get as many Drupal users as they could to participate in the redesign. So, through a number of collaboration mechanisms--setting up a Twitter account to follow mentions of Drupal, opening a Flickr account where the community could post pictures, and actively engaging the existing Drupal forums--they opened the design process up so that anyone in the Drupal community could share in the process.
Conventional wisdom says that design doesn't work as a democracy. It takes the genius and inspiration of a small team or one person to understand what the customer needs, and design the right solution. As Henry Ford said it best, "If I'd asked my customers what they wanted, they'd have said a faster horse." So I'm not surprised that according to Mark Boulton, the lead Designer on the project, many people though that this type of open process would fall flat on it's face. I'm not convinced that it won't, but from what I've seen, the site is looking good.
It's still in prototype phase, so it remains to be seen if the redesign, once implemented, will be a success. but you can get a look at the evolution of the design here, and of course follow the links to the discussions. It's a fascinating look at one designers experiment in design by community.
Topics: CMS, Design, drupal, opensource
iPhone SDK: UIViewController Testing & TDD
Unfortunately there are not enough examples out there on how to test view controllers with the iPhone SDK. My hope is to remedy that a bit by sharing some techniques I have been using to tackle the problem, particularly in keeping with the spirit of TDD along the way.
First, If you have not already done so, configure your project to use GTM. This is a bit of a no-brainer as it currently stands. Until Apple comes up with something better, GTM is the way to go. It works as advertised, and is a credit to the folks at Google for providing this toolkit.
Now then, many tutorials on the web seem to imply that one should test somewhere in the middle by suggesting to add a few outlets to your controller, fire up IB and wire up your view to your view controller before you even start to think about testing any of it.
Testing controller logic means working under the assumption that you have wired up your view components correctly to match the controller's actions and outlets. Wire up an element to the wrong action (or worse, forget to wire it up at all) and you can easily learn to rely too heavily on manual testing. While this might be acceptable for small one-off applications, within a team of developers practicing collective code ownership, this kind of error can cost real money over time. "Thanks for caring, but I'd rather have a unit test."
Now then, let's take a look at some code!
The Truth About Designing For Security

Security is an area of concern where value and cost are often difficult to estimate. While big mistakes made early on in many areas of an application may prove difficult to correct, this is especially true for security, since its specifications often model a direct reflection of an organizational structure.
And all too often, dysfunctional organizations create dysfunctional security requirements.
It is common knowledge then that a failure to account for security from the start can prove much more costly in the end. However, over-engineering security needs can require so much effort that your team may not have enough time left over to actually build the very features you are trying to secure.
I find the following two points very useful to keep in mind when participating in discussions concerning security regardless of the application, but especially when working under the assumption that a new application needs the same kind of security model as the old application:
- All security models are idiosyncratic
- Never underestimate the cost of being flexible
These two items work as polar opposites of each other: a flexible system can accommodate many types of organizations, but not without the added cost of training, installation, documentation or maintenance. On the other hand, a static model is cheap to build, but rarely captures the nuances of an organization's structure, particularly as business needs evolve over time.
Continue reading »
Topics: architecture, Design, Security
Upcoming Conference: FITC Chicago 2008, June 22-23
Another Chicago area conference coming up: FITC Chicago 2008, from June 22-23 at the Chicago City Centre Hotel & Sports Club, 300 E. Ohio. We're even supporters.
So what is it beyond the platitudinous "design and technology" event?
Obviously there's going to be lots of talk about how to develop Flex and Flash applications. Also how to develop online/offline apps with Adobe Air. Heck you'd think Adobe was a sponsor.
If designing RIA's with Flash/Flex/Air is your thing, you want to be here. It's not free, but based on last year's event, well worth the $125-$250 (depending on which sessions you go to).
Update: If you sign up here with our special ninja supporter code of PATH15, you get 15% off.
Topics: Adobe, Adobe AIR, Announcement, Conference, Design, Flash, Flex, Web/Tech
Pixel by Pixel…Or how I spent my last 2 weeks designing a few icons
"Our product is shipping globally, and we're not going to customize each device to the language of it's destination country. So we need you to design a set of icons that will be used in place of textual messages."
Challenging, but simple enough, right? Immerse yourself in the product, do some user research, brainstorm designs that are meaningful, descriptive and culture neutral, and there you go. Oh, and one more thing...the device's display is 128 x 64 pixels with 1 bit color depth.
Such was the nature of the project I recently worked on, and it was a challenge of a very different kind then I had faced in a while. With either greater resolution or more color depth, It's relatively easy to depict pretty much anything with a high degree of recognizability. Shading, perspective, non-linear surfaces are all time consuming but doable with one or the other. Yet with only 2 colors and not many more pixels at your disposal, your so much more limited in what you can do. Take a look at some early GUI icons to see what I mean...



Since I couldn't use more than 2 colors, I couldn't anti-alias, so I was basically confined to horizontal, vertical and 45 degree diagonal lines. Forget about perspective. Since true perspective doesn't involve straight lines, depicting a product from an angle on such a small scale is out of the question. And shading--which is essential in illustrating that a surface displayed head on is curved--is just a matter of starting on the darker side with a high frequency of black, and then lessening the frequency as you move to the 'lit' side of the surface (Take a magnifying glass to a newspaper add to see what I mean). Again, not an option here due to the small screen size, there just want enough room to do that. I felt a lot like a writer being asked to weigh in on a complicated subject using 50 words or less. They say brevity is the soul of wit. I had to be clear and concise if I had any chance of success.
At 128 x 64, every pixel matters. And at 1 bit color depth, rotating, scaling or otherwise transforming anything in Photoshop is useless because the software automatically anti-aliases, creating shades of grey that were forbidden. So I had to design pixel by pixel--make a 1 x 1 selection, put my hands on the keyboard cursors and get to work. See Wikipedia's entry on Pixel Art for a good reference.
As it turns out, I was more at home on this project than i though I would be when found out the requirements. You see back when I was a kid, the first computer graphics program I ever used was on my father's DOS machine. The program itself wouldn't fit on the computer's hard drive, so it had to be loaded via floppy disk--the old 5 1/4" ones. The computer didn't have a mouse, so almost everything I created had to be tediously drawn pixel by pixel using the cursor keys. It took me months working 2-3 hours a night, but I created some pretty good stuff. In particular, I remember drawing a hockey rink, with players, stands and all, which I'm pretty proud of. Using Photoshop/Illustrator now, with the capabilities so far advanced over what I had to work with at that time, It's hard to see how I did what I did, or for that matter why I spent months doing it. But there's something about taking time to do something right, struggling through the frustration that comes with the absence of 'Undo', picking yourself back up after making a mistake that renders 10 hours of work useless. Creating art is a sprint. Back then it was a marathon.
So I forgot about my mouse, left the color picker behind, and zoomed in at 1600%. I soon found the hang of it again, and I got in the groove I remembered from way back. After a lot more time than I though it would take, I had a set of icons that worked...and that's the key. And in the end, I feel a little more satisfaction than I would have if I was allowed to let Photoshop do it's magic.
Topics: Design
Use Case Diagrams
Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.
For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.
The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.
Topics: Best Practices, Design, Information Architecture
The Curse of Knowledge
You can never know too much about something, right? Wrong, at least according to a December 30th article in the New York Times. As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."
Reading the article, I couldn't help but think back to my own experiences with this same sort of issue. I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.
Now I see that it's part of a larger problem of expertise and creativity. The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do. The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape. The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.
According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking. Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.
Powered by ScribeFire.
Topics: Best Practices, Design, Design Patterns, Domain Knowledge, Ideation, Story Telling
Design can be Used for Good and Bad
Every so often I'm rudely reminded that much of the information I get comes from a source who's goal is to sell rather than inform. It is those times that I'm also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.
Case in point. I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day. I choose Yahoo over the many others out there because I'm used to it. It has a simple interface and I know where everything is located. It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable. However I just recently noticed that Yahoo Finance is serving some text ads on the site now. I wouldn't otherwise be too bothered by them, but they've been designed for the express purpose of looking like real (un-sponsored) content. They're right up there on the right hand side of the page, occupying the top of one column in a three column layout. The ad titles are just about the same color as the headlines and links on the rest of the site. And while the other section titles are all orange and bold--designed to give structure to the page and let you know what section your in-- the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) 'Advertisement' header.
This really infuriates me, especially because it's a finance site, and I can't help but notice the content of the ads. For instance, right now I'm looking at the front page, from left to right I see a snapshot of the Dow's performance today, a headline saying 'Stocks mixed ahead of jobs report' and a couple of blurbs on 'Hottest China Stock' and '16 Hot Dividend Stocks'. Now I'm sure you can guess which ones are ads. And yet I can't help but see the ads and incorporate them into my understanding of the days financial news. They were designed to be scanned, and that's exactly the kind of information I need to be able to filter out when I'm scanning a page like this.
The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.
Powered by ScribeFire.
Dasher - A new way to write
I simply love finding these little gems on my weekly web excursions. This time it's a fascinating new piece of software out there called Dasher, and it allows you to write without typing or scripting. What's that you say? How else can you write? Well...The basic idea is that current methods of typing are inefficient, because they don't learn. Let me explain. Although there are x number of letters in the alphabet, every pressed key reduces the number of available choices for the next key press, and increases the odds that other specific keys are pressed next. For instance, 'E' is much more likely to be pressed after 'H' than 'B' is, and 'O' more likely after 'G' than 'C'. On current writing technologies it's up to the user to learn to be more efficient at writing He than Hb or Go than Gc. But that doesn't need to be the case. By taking advantage of the learning and memorization power of the computer, it's possible to create writing interfaces that guide you through the process rather than just recording what you type. If you'll indulge me in some metaphor, imagine rowing down a river. Dasher is the river with a strong current to wherever your going, and existing typewriting technology is the river with no current whatsoever.

What Dasher does is use language patterns to present likely letters and words to the user based on the letters or words they have already written. The goal is to make writing more efficient by reducing work. There are no keys to press using dasher. In fact the mouse is never clicked. The interface allows one to write by simply navigating the mouse down a path--or tree--through the alphabet. The start screen displays all 26 letters of the English alphabet. You select a letter by moving your mouse next to it. As letters are selected, Dasher displays all available letters again, but this time those more likely to be chosen are larger and therefore easier to select. As you write, you move forward through the tree, and entire words and phrases are displayed in order of likeliness.
Dasher needs some work before I start using it instead of my keypad, but the idea has real merit, and it deserves to be explored more. As an interface designer I see at this tool as a great example of how simple interactions, when thought about creatively, with nothing held sacred, can have potentially revolutionary effects on the way we interact with technology.
Powered by ScribeFire.
Topics: Design, Flow, Interaction Design, Rich Interactions, User Experience
DUX2007 - Ubiquitous Computing
Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.
Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service
Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.
As designers, then, our challenge is to design for these product/service ecologies.
Back to the Nike+: although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.
Some final thoughts from Greenfield:
- As designers, we can no longer assume that the product we design will be a standalone product.
- Everything that can be networked, will be.
A final thought from me: it's an exciting time to be designing.
Technorati Tags: Design, User Experience, Usability, DUX07
Topics: Best Practices, Design, Ideation, User Experience
DUX2007 - Data Visualization
Data visualization was touched upon a number of times throughout the DUX07 conference.
In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.
One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:
- allows us to immediately see how items are related to one another;
- gives us a more immediate way to see patterns;
- becomes a default to try and understand huge amounts of information.
In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.
Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.
Fascinating ideas and I know we're just scratching the surface of its potential.
Technorati Tags: Design, Information Architecture, Usability, DUX07
Topics: Design, Design Patterns, Information Architecture
DUX2007 - Simplicity
Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.
At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?
To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:
- time - can I spend the time learning to use a new product? no? then it's not simple
- money - can I spend money on a new product?
- physical effort - does it require exertion beyond my usual effort?
- brain cycles - do I have to think for a long time?
- social deviance - does it go against the social norm?
- non-routine - does it break my routine?
These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.
Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.
Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.
Technorati Tags: Design, Information Architecture, Usability
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue

