Dexo Design » design process

Design Process at Facebook

Russell Wilson — Thu, 27 Aug 2009 14:03:31 +0000

Caught this writeup from Luke Wroblewski on how Facebook designs their software. Key takeaways for me:

design team delivers front-end code
share early and often; design is involved start to finish
design team size = 25 (out of 1000 employees)
design is iterative – know from the start that your designs are “experiments” (my words) and may/will change

See the whole article here.

Design Guiding Principles

Russell Wilson — Sat, 11 Jul 2009 22:47:53 +0000

John Schrag has just written a post titled Values in Software Design Practice.
To summarize, John and his team came up with two lists:

Appropriate order of actions:

Setting Goals before Taking Action
Understand Problems before Generating Solutions
Designing before Writing Design Documents
Validating Designs before Investing in Code
Steak before Sizzle

Values:

Validated Data over Expert Opinion
Quality of Data over Ease of Data Collection
Complete Workflows over Long Feature Lists
Achieving Results over Writing Reports
Collaborative Design over Design by Referendum or Design by Fiat
Ease of Use over Ease of Coding
Well-designed Critical and Common Workflows over Complete Coverage of Every Possible Workflow

Ironically, I was just about to begin an almost identical process with my team next week. We are having our first “UI Roundtable” with development and “Design Guiding Principles” is one of the topics. I plan to take John’s team’s list into consideration when developing ours.

4 Step Simple UI Design Process

Russell Wilson — Mon, 03 Nov 2008 16:21:29 +0000

Working this weekend (we’ll call it Project-A) I noted an informal process I follow when designing workflows/interactions for applications. This comes after initial research on users, goals, requirements, etc.

Essentially (detailed steps omitted) it boils down to four steps:

1) The big chunks

What are the big chunks/concepts and how do they relate to each other? For example, Project-A has a dashboard, reporting, system configuration, and object management. The user is most often expected to start with the dashboard and then drill into problems, but may also go directly to reporting. The interface needs to support easy and intuitive access to both.

2) The small chunks

What individual components will be needed to build the big chunks? (a) flat and hierarchical lists, (b) small and large lists, (c) navigation, search, paging, indexing, (d) dialogs, wizards, etc. It is important that templates are developed for these chunks to promote consistency and conceptual integrity. Design patterns such as progressive disclosure, overview/detail are considered here because they may require specific components to be implemented.

3) Fitting the chunks together

How can the components be fitted together to create the big chunks and to produce the desired design patterns? This step usually produces the essence of the workflow but doesn’t really tackle the details or special cases. For example in Project-A, a dashboard of summary data is used with drill in capability to detailed reports (design patterns: progressive disclosure and overview/detail)

4) Finessing

This step deals with styling and dealing with any special cases. Graphic design concepts such as visual hierarchy are applied to guide the user visually and emphasize key elements.

The steps are iterative. For example Step 3 can/will identify additional needed components (Step 2) and in many cases both Step 2 and Step 3 have led me to reconsider the big chunks in Step 1.

I have used this simple process countless times to design software applications.

Challenges to world class software design

Russell Wilson — Thu, 09 Aug 2007 02:37:00 +0000

Every job has its challenges. As a programmer, I spent long hours fixing bugs and finding workarounds. As an engineering executive, I dealt with resources, schedules, and politics. And as an entrepreneur, I struggled to find customers and generate revenue.

But designing software is tough. I’m not talking about the creative work – that’s our passion and we love it. I’m referring to the “tax” we pay for doing what we love.

So what makes up this tax? What challenges am I referring to?

1) Everyone thinks they are designers

Developers, product managers, sales, and even customers, can’t resist their own needs to create or invent by suggesting ways to change an interface or add capabilities – “let’s just add a drop-down to the top…”. Either in the form of “design on the spot” during a product meeting or customer visit, or a developer going ahead and “fixing the problem” without waiting for input from design, it happens often, and reflects perceptions and lack of understanding of the design role and expertise. It can also reflect poor adherence to process, or lack thereof, and a need for cross-department executive sponsorship and continued support. (I am not suggesting that no one can give input to the design process; many of our best designs are the result of collaborative efforts with product management and sales.)

2) Design is a nice to have

I’m always perplexed by this one, but many bottom-line executives still perceive good design as a nice to have. No, not at Apple or Intuit (I see more design-related job postings from Intuit than any other company – it makes me wonder if they just want to interview everyone they can, or if Intuit has a Wonka factory somewhere full of designers dressed like ump lumpas, all building accounting applications). Apple and others have helped to move this forward, but I still run into the skeptical eye from time to time. Another manifestation of this is when a new product or concept is attempted and the strategy is to “get something working, find some buyers, and then make it better.”

3) Who makes the final decision?

The Biltmore Estate is a remarkable architectural achievement, and is commonly considered the result of a single vision where the overall design was driven and conceived by one person. Frederick Brooks states that “conceptual integrity” is the single most important factor in the development of successful software applications. But often, with software design, there are many stakeholders, business and marketing agendas, and the need to create something as soon as possible. The nature of software design and development within high-tech companies doesn’t seem to lend itself to the purity or grandeur of a project like the Biltmore where the “genius” is given free reign to produce a work of art. It’s difficult to find the right balance between art and business in software design, and this is evident in the careful politicking among the design executive and various stakeholders to decide what gets built and what doesn’t.

4) The difficulty in justifying designs to critics

True, the best justification comes from users, and you can get that (to some degree) from usability testing — assuming you have the time and resources to conduct formative testing. But what about colors? What about visual treatments that are more subjective? What do you do when the product manager says “I hate that blue — why do we have to use that blue?” (I recently emailed a color wheel to a large group of employees at our company – that was a big mistake.) There are many cases where I wish I could just say “just do it that way, trust me!” My boss suggested that I respond with a standard “thank you for your input” for things such as this.

Well, those are some key ones, but I’m sure I’ve missed several. I invite anyone who reads this to submit their own design challenges. This is a work in progress and I intend to update it with the best ways to address these challenges.

Prioritizing product ideas

Russell Wilson — Mon, 16 Jul 2007 17:18:00 +0000

Adam Polansky from boxesandarrows describes a method for prioritizing product ideas called “Faceted Feature Analysis”. I particularly like the idea of giving independent voices to development, business, and user experience as part of the process. – Russ

http://www.boxesandarrows.com/view/faceted-feature