Team MAGIC, or “The Magicians” (as they are known within Alley) found themselves with a rare opportunity to link their in-person retreat with the American Alliance of Museums yearly conference in New Orleans. Team Magic has worked on many museum projects and a few members of the team were speaking at the conference last year. So, instead of choosing a random city somewhere in the continental United States of America, the Magicians set their sites on the birthplace of jazz.
You want to refresh the look of your site. You have the approval from your stakeholders, the budget and resources, and goals for the new design. But how do you actually kick off a design project?
It can be intimidating, especially if you haven’t been through this process. We thought it might be helpful to share some tips that will help you get the results you need from your project.
- Listen. You probably know a lot about your product, but taking the time to talk with key stakeholders—executives, board members, department leads—can uncover important requirements for your new design. Involving these folks early in the process sets the stage for their productive involvement as the project progresses. When they see design proposals, you can present them in the context of your previous conversations and demonstrate how their concerns were addressed.
You’ve probably heard “user centric design” or “you are not your user” a thousand times by now. But surprisingly few organizations embark on site redesigns with recent user research in hand. Talk to some people who use your product. Even a few users can shed light on what is important to your audience and what they wish your product would do for them. These early insights can save time and money and make it clear which path to follow.
- Don’t break the momentum. When we conduct discovery workshops, we encourage participants to block their calendar, put away their phones and “single task.” Once they’re focused, we don’t just talk for a while and then go home. We balance discussion with hands-on workshop exercises that identify key product challenges and produce homepage sketches, navigation proposals, or template requirements. Doing this work while we are all focused and immersed in the product results in nascent deliverables that we can immediately refine and build upon, rather than trying to infer them days later from our workshop notes.
- Design in browser. A traditional website design process used to work like this: a designer opens Photoshop and starts producing a library of static design mockups. These go back and forth with the client through many rounds of revisions and are sent over to developers who are unhappy that they came late or are difficult to implement. Later, the client sees the designs on their development site and to their shock, the work looks somewhat different than the pixel-perfect mockups that they approved weeks ago. If requirements change, everyone’s design and development work is wasted. Instead, we choose a few key site templates and produce a limited collection of static wireframes and design mockups, just enough to illustrate the site’s styles and design patterns. From there, we pair designers and developers who iterate in the browser through a working prototype. Not only is this a faster way to work, stakeholders can test out interactions early across devices and raise early concerns about look and feel. Nobody is surprised and everyone is on the same team.
- Science! Designing and building a website consists of many tiny decisions that add up to a successful product. Where should a button go? What call to action text is most effective? Does my audience like blue or red? There will be times when the right answer is truly unclear. This is a sign that more research is needed. We take a “scientific method” approach to our design; we make a hypothesis, test, and iterate. We run tests during or after a launch that range from on-the-fly testing of user interface elements to highly coordinated efforts to test an entire user flow or in-browser prototype. Our designers, research teams, and developers swarm on a problem, moving through the process of testing and iterating efficiently.
We hope that these suggestions provide insight into some things you can try in your own design process. If you’re interested in learning more about these tips or other aspects of our approach to design work, don’t hesitate to reach out! We’re always happy to share our learning.