Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I a novice UX designer and my current assignment so far has been designing UIs for the "version 2" of existing services - which means I use data points for improvements of existing UI which I gather either through web analytics or usability. The data helps in convincing the dev teams when I am asked why I am making a certain change. Now my new assignment involves creating UIs for a new service within my client organization.

Can you please share your thoughts on how I can approach a new service? I will not have any data points to refer to.

share|improve this question
    
You're asking a very broad, general question. Can you try to specify it a bit so we can help you out? For instance, what kind of service is it? What challenges will you face? –  Rahul Aug 10 '11 at 16:23
    
The client is a retailer (startup) that is planning on launching a retail website for their electronic products. I want to understand how to design websites from the scratch. The goal is to create a user friendly ecommerce website. –  Tara Aug 10 '11 at 17:19
add comment

4 Answers

up vote 3 down vote accepted

As a user experience designer, your first priority is to zoom way, way out to birdseye view and get a good feel for what's going on. That means identifying your market, your users, and your stakeholders. Afterwards, you can zoom back in and start getting detailed.

Before you start

Learn the market

Start reading all about products and services that are like what you need to design. Start following competitors on Twitter, subscribe to their RSS feeds and newsletters, and really inundate yourself in what's going on. Your goal is to be able to answer any questions people will ask of you about the service you're designing. How will it fare against competition? Why are you choosing to approach the problem this way rather than some other way? What can you learn from others' mistakes and successes?

Meet your users

Go out and talk to people who will be using the software. This will be easier if it's an internal app, but even if you're designing for a broad group, you'll gain a lot of understanding from meeting and talking to your audience. First you need to identify who these people are (and are expected to be). Your stakeholders will be able to help here - talk to them and find out what their assumptions are about their expected users and market.

Construct personas that broadly define who you expect to attract to the service. Then schedule meetings with people in those groups. Interview them (informally) to learn what they care about. What are their concerns? Do they use any competing products? How do they feel about those? Doing a survey with a larger group works well too.

Manage expectations

If you have a group of stakeholders, look into ways to organise and prioritise their goals in order to create a loose information architecture with which you can start. There are ways to do this, such as mental modeling or card sorts.

Identify who the "real" stakeholders are and make sure you and they see eye-to-eye on the project's goals and expectations. The biggest reason projects go badly is when you don't manage clients' expectations correctly. Make sure they know what you're planning to do, they understand why, and they know what to expect (and when). Give them clear, measurable milestones you intend to reach.

Read Mental Models for more on mental modeling.


Once you've figured out what to do

Paper prototyping

Once you think you have a good understanding of market, audience and expectations, it's time to take a step into the UI with a prototype. Early on it might be a good idea to just do a paper prototype as you will be able to iterate very quickly and bring stakeholders on board. Schedule a session with some of them and get everyone drawing and thinking visually. How will information be organised? Remember to focus on key usage areas of the service, not the homepage - that comes last and will be a result of all the other decisions you make.

Information architecture

After paper prototypes you need to model your information architecture. How will this service work? You need to express the structure of the service in a language team members and stakeholders can understand. A lot of people use Keynote or Visio to make things visual. The goal here is to communicate and define. Spending time here will help you out a lot later on as it gives you time to really think things through. Don't spend too much time - you need to get into designing the UI fairly soon. But make sure you've loaded the structure of the service into your brain and you can think to yourself "how should X work?" or "do I need Y?" without having to consult other things. Make yourself the expert on the domain model.

Content strategy

You need to know what kind of content goes into this site. Who's responsible? When will it happen? What tone of writing? How are you handling microcopy? Since people come to websites to (mostly) read, this is an important step in the process.

Read Content Strategy for the Web for more.

HTML prototyping

After IA you should make things real as soon as possible. You can do wireframes before this stage, but my recommendation is to get real as quickly as you can. After all, you're creating a user experience, not a bunch of static pictures. Start work on mocking up some screens with HTML prototypes, making sure to focus on flow and state. How do different users experience the service? How do transitions from one screen to the next work? How does the service feel when you click around it? Spend time thinking about copy. What feels right?


Now what?

After these steps you should have a rough demo of what you think the app should be and do. During the way you should also have been in constant feedback loops with stakeholders and users, validating your thinking and making sure you don't assume incorrect things. Your next step is to take the prototype and get usability tests running. From there, you'll have a solid foundation to work from and you can start doing iterative prototyping and continue designing the service until you're ready to let some people start using it. Your focus should be to launch quickly so you get out of the imaginary world of development and put the product in the hands of real people.

share|improve this answer
add comment

After spending time making improvements to an existing thing, it can be daunting starting something from scratch! Think about what you DO know - who will be using it? What sort of goals do they have? Can they be roughed into a few personas, to stop you trying to design for everyone? Thinking through those questions, and preferably getting out there and speaking to the people who you're designing for, will be a good start and will give you the foundation for your design.

You may have heard this before in a variety of ways, but some user contact is always better than none - even if you think you will not find budget or resource to 'officially' interview your users, doing it off you own bat will make your task so much easier initially, and more importantly give you that confidence to defend your decisions later.

I'm on twitter at @persuadesign, give me a shout if you would like any support in personas or just getting going on this!

share|improve this answer
add comment

When it comes to "What to build?", I'd talk to some of the people you think would use the site. Find out whether the pain point you're trying to solve is one that they have. If you're building it for people like you, it's a little easier and you can go with your gut more. The book "Designed for Use" is a pretty good introduction into figuring out where to get started.

My approach for "How to design it?" is to do a ton of research. You can look at Yahoo's design pattern library http://developer.yahoo.com/ypatterns/ . I collect a bunch of research in the tool LittleSnapper. For example, you might collect a bunch of screens for "Sign up flows" or "User Profiles". You can then refer to them when doing it yourself. It helps when you sell it to others because you can say "This is how Facebook does it". The process of collecting the screenshots is most valuable because it helps you understand more of how and why they are doing things in a certain way.

When designing features like sign up, don't reinvent the wheel. Use tried and true methods. When doing features that will make the site a success, spend a lot more time experimenting. Don't be afraid to try new things and go out on a limb, but do it in a cheap way. Paper and sketch wireframes are your friend. Do enough that you'll be able to figure out whether or not it'll work. The more confident you get in the idea, the higher resolution it should become.

Take some risks, and be prepared to be wrong. There is no "right" way to do things. There are only "better" and "worse" ways.

share|improve this answer
add comment

Lot's of great advice here, but don't be overwhelmed.

Just keep moving the ball down the field and get to a rough working version that you can put in front of real people, test and iterate just like you were doing before.

  1. Talking to real users early and often - learn their fears and hopes.

  2. Find great examples of very similar products and study them well. Become a user if you can. Imitate what works, improve on (and test) what needs improvement.

  3. If possible - iterate like crazy! You don't design user experience so much as disover it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.