Topic: Design

Who values your product and do you value them?

Michael Walkden, Friday, March 12, 2010 @ 11:26 am

photo credit: victoriapeckham

We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Storytelling in Design

Bob Moll, Friday, February 26, 2010 @ 6:04 pm

Instead of a "loading" animation that we may bail out on, why not tell a story? I was impressed with this technique used by BMW.  They are running banner ads on NBC's site which hypes the upcoming Olympic events. You see a car in the banner ad, you expect to click and see more car. But you don't. Instead, a blank white screen with just a few short words pops up. But the words tell a quick paced story. phrase by phrase, of what joy is. Joy is Timeless. Joy is Freedom. Joy is Innovation. And below those words is the "loading" indicator. 10%, 20%, 32%, and so on. A nice example of storytelling used in design - if you are going to make someone wait (or have to, because you are loading a high-end car video), consider getting them engaged with a story.

http://www.bmw.com/com/en/insights/technology/joy/bmw_joy.html

• Digg
• Reddit
• del.icio.us

Comments (0)

User Experience Design

Your SDLC or Your Product – You Decide

Michael Walkden, Wednesday, December 9, 2009 @ 10:33 pm

…or the telephone game

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Art vs. Design, the Art of Design, or the Design of Art

Vena Chitturi, Thursday, September 24, 2009 @ 9:14 am

A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.

Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design's goal is to solve a problem, whereas art doesn't necessarily always have a problem to solve. I could talk about how art doesn't necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn't require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.

But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it's also about solving a problem beautifully. Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

A First Impression of Flash Catalyst

Sholom Sandalow, Thursday, July 23, 2009 @ 3:29 pm

Spent some time playing around with Flash Catalyst, which was released by Adobe as a public Beta yesterday. I downloaded it today and got started on some of the tutorials Adobe labs has put up.
My impressions:
It's pretty neat stuff. I could see myself prototyping with it, although Keynote and Acrobat are my tools of choice at the moment.
From my limited time working with it, Catalyst's main function is to make it very easy to take Photoshop or Illustrator compositions and turn them into fully (front end) functional interfaces, complete with animations, transitions, fades, buttons states etc. One of the tutorials had me import artwork of a scrollbar, in 4 layers. Creating an actual scrollbar and hooking it up to a canvas was as easy as selecting the individual layers and telling catalyst which part of the scroll bar it was (up button, down button, track and thumb). It;s also super easy to connect user actions to specific screens (or states, as Catalyst calls them).
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

User Experience Design

Integrating Design and Agile Development

Bernhard Kappe, Monday, June 22, 2009 @ 5:04 pm

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

The Costs of Building Secure Applications

Ivan Moscoso, Wednesday, March 25, 2009 @ 11:50 am

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.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

software development best practices

A New President, A New Whitehouse.gov

Sholom Sandalow, Tuesday, January 20, 2009 @ 12:46 pm

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Drupal.org redesign – An Experiment in Design by Community

Sholom Sandalow, Friday, January 9, 2009 @ 12:14 pm

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

User Experience Design

iPhone SDK: UIViewController Testing & TDD

Ivan Moscoso, Tuesday, November 18, 2008 @ 11:47 pm

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!

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development

The Truth About Designing For Security

Ivan Moscoso, Tuesday, November 18, 2008 @ 12:49 pm

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 »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Upcoming Conference: FITC Chicago 2008, June 22-23

Dietrich Kappe, Friday, May 30, 2008 @ 7:27 pm

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Pixel by Pixel…Or how I spent my last 2 weeks designing a few icons

Sholom Sandalow, Wednesday, May 7, 2008 @ 9:05 pm

"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.

• Digg
• Reddit
• del.icio.us

Comments (0)

User Experience Design

Use Case Diagrams

Alice Toth, Tuesday, March 18, 2008 @ 3:35 pm

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

User Experience Design

The Curse of Knowledge

Sholom Sandalow, Friday, January 4, 2008 @ 11:38 am

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.

• Digg
• Reddit
• del.icio.us

Comments (0)

User Experience Design