Real-World University Web Design: Get to the Root of the Problem

Published 23 Mar 2006

I thought I’d document the process that I have been using lately on my university web designs, since after about 2.5 years of refining I have come up with one that actually seems to work well for me and my clients. This is shaping up to be another series; in this part I’ll talk about starting at the beginning.

A key part of the beginning of the design process is having access to a group of talented, creative people who have expertise in an area different from your own. They could be writers, graphic designers, programmers, system admins, art students, etc. I would try to stay away from faculty members (did I just say that?!) unless they are unjaded and not pressed for time. The two key qualities of the group members is creativity and expertise in some area. If you work as a team of one like I do, you may have to get creative in getting access to these folks, but it will probably be worth it. Chances are that some exist within your parent department, and others exist in those departments you have to work with all the time (IT if you reside in PR, and vice versa).

The process starts like this:

First, define the actual problem you are trying to solve. Try to remove all technology and design from this definition. For example, “we need an interactive way for folks to look up campus buildings and their locations” is better than “we need to use the Google Maps API to provide campus maps” and also better than “we need to update our online maps because they are outdated and ugly”.

If you do “client” work for academic or administrative departments, you will need to guide them during meetings to get them to tell you what it is they really want to accomplish. Why do they want to redesign their site? What do they want to get across to their users? What is the most important message they want to convey? This may sound strange to folks in the for-profit world, but university clients often come to me for web work without a clear vision of what they are trying to do, much less why they need to do it.

Once you get the problem boiled down, start talking about it with the aforementioned creative folks. They will start brainstorming ideas— “wouldn’t it be cool if“s— and will likely bring up points that you hadn’t thought of. Write things down, even if you don’t think they’re technically possible. Folks may come up with resources, other sites they have seen that they like, a cool thing their friend is doing, etc.

Often, from these conversations, I learn that the problem is not what the client thought it was, and what’s more, it’s not what I thought it was, either. The day I realized this was a real eureka moment for me. How can you make an effective site if you’re solving the wrong problem?

Once you figure out the problem you can start working on the best technology to tackle it, and then you can start working on your standards-compliant accessible code. And then you can usability test it and blah blah blah. The point here is not to get caught up in your own little corner of expertise before you get the big picture nailed down. I have spent a lot of time going back and fixing sites— sites I built— that are ineffective simply because they’re trying to do the wrong thing. Many times this is because I didn’t talk to anyone else about what I was doing, and many times it is because I took the client’s request at face value and did just what they asked for.

This first step— defining the problem— is much harder than it sounds. And, even though it doesn’t call your coding or CSS skillz into play, it is probably the most important part of the whole process.

How do the rest of you get to the root of the problem? Any tips or techniques to share?

Filed under Recommended, University Web Development