Bluespark's User Experience Design Principles
Rick Cecil
Thu, 04/12/2012 - 19:01

The success of a project — any project — begins with the right mindset. Without the right understanding of the world around us, we are limited in what we can accomplish. But with the right mindset, we can accomplish great things. The key to Bluespark's success on project after project starts with the right mindset as embodied by a core set of design principles: a core set of values that we use to approach every project.

Powerful goals create powerful results
The underpinnings of a successful project begin before you even write the RFP: What are you trying to accomplish with the project? Presumably that’s what your RFP or Statement of Work is intended to answer, but many times, these things get lost in the nuts and bolts of the hundreds of details that you’re trying to capture in these documents. So the first thing we want to understand are the real motivators behind the project and how do these motivations translate into business and user goals. Many times, through the process of discovery, we uncover goals that the client wasn’t even aware they had. Other times, we identify conflicting goals — conflicts within departments or even conflicts in what the client is trying to accomplish and what is being asked for in the RFP. Which leads us to our second principle: Question assumptions.

Question assumptions
You make assumptions. We make assumptions. And we all end up making asses out of ourselves because we made so many damned assumptions.

We do our best to not take anything for granted. If you specified something in the RFP, we want to know why it’s in there and how important to the project’s success it really is. We want to know what functionality we can trade out for other functionality or ideas that might help you better achieve your goals. Nothing is off-limits here. Not because we like torturing you, but because this process has proven to deliver results. If you ask for an apple and I give you an apple, but what you really wanted was an orange, it’s my fault for not pushing you—for not questioning your assumptions about what you’re looking for. It’s the same with functionality, too. Often times clients have very specific requirements around some functionality they want. If we were to deliver on the functionality, though, will you like what you see? Maybe you will, but it’s better to question why each bit of functionality has been requested and re-focus the feature-set on our real goal.

Ultimately, by understanding and questioning the underlying assumptions — assumptions you might not even realize you’ve made — we can tackle the real problems the project is trying to solve.

Talk to the User
You have your goals — and the assumptions driving those goals, and maybe we’ve even created some compelling designs around your powerful goals, but how do we know that what you want to build will actually achieve your goals? We don't, not really. We are missing some key insights that we can only gain by talking to your users. Let me illustrate.

Did you watch the move The Social Network? Remember the scene where Zuckerburg is getting pressured from his friend to launch the site, but Zuckerburg insists that it’s not ready? It’s not until he gets asked about a particular girl’s relationship status that he understands what the site is missing. He rushes home, adds some simple code: Relationship Status. And then voila! He’s ready to launch. Zuckerburg wouldn’t have made this breakthrough had he not been talking to someone from his potential audience.

Of course, in the conversation where the insight happened, Zuckerburg wasn’t trying to test his new product — he was actually on his way to class when the other student interrupted him. But the idea remains solid: talking to your users or potential users is the best and only way to really understand how they want to interact with your website or web application and it’s a critical part of how we work.

Don’t mistake me. We don’t call up random users and ask them: “How do you want to interact with this website?”

It’s not your user's job to know this — it’s your job. But buried deep within the daily rhythms of their life lies the answer. We can use a range of techniques from contextual interviews to iterative usability testing to understand their real needs (versus how they describe the need), and often we combine these two techniques to great effect.

Iterate
Great websites and web applications do not emerge from our process fully formed. What we deliver is the core of a great idea that, if done right, will deliver some key business value. It’s a starting point that over the course of time, can be refined and sharpened into a powerful tool.

What we’ve learned over the years is that websites are not fixed and user's needs change over time. Just because the project has ended does not mean that the product is finished. Just because we met your user's need, does not mean that their needs won’t change over time or that new needs won’t arise.

No, what we give you is a building block, the start of something great. And with Drupal as your backend, you will have the technology to grow and adapt your web presence as your audience needs grow. And that brings us to our last principle: what we want to deliver is a product that is as simple as possible so that you don’t spend time building something only to find, after launch, that you only needed half of what you built.

Start as simple as possible
As people, we have a tendency to want to launch web products and their features in the most pristine, complete state possible. If we picture a gallery, we envision Flickr. If we envision a blog platform, we envision Blogger or Wordpress. Nevermind that these services started out very different than what they are today — and, very possibly, are meeting a different need than what you’re trying to accomplish with your web product.

The culmination of everything we’ve talked about to this point leads us to this principle: Start as simple as possible. The first version of the gallery on your site might not be an exact clone of Flickr. And, really, that’s okay because you don’t want to be an exact clone of Flickr — otherwise, why aren’t your users just using Flickr? By starting with fewer features and focusing on outcomes, we give you room to learn from your users, to understand what they’re trying to accomplish. We also give you a chance to understand and explore how you want to interact with your customers, to see how you can build a truly unique user and brand experience for your users.

Filed Under

Drupal
Drupal Planet
Best Practices

Add new comment

Area

User Experience (UX)

CTA

Partner Next Project