I’ve been in several meetings where the words “high level design” was bandied about by designers and stakeholders. The importance of a high level design… well, it was unquestioned. A high level design was absolutely vital, to ensure the success of the project. Everyone agreed needed one, of course.
At one such meeting, a long time ago, someone asked the obvious question,”What is a high level design?” That person was me. I kinda sorta knew what it was, but not really. My asking resulted in a very heated discussion with my fellow designers. I found out that none of the people in the room could define it succinctly… and several disagreed with each other’s definitions. We hashed it out, and settled on a definition that was agreeable to all concerned.
After some research, I’ve settled on my own personal definition of what a high level design is, and what it brings to a design project – which is quite a lot, in my opinion.
A high level design represents the “foundation” of what you are trying to produce as a design solution. It is the core definition of what it is, who it’s for, why you are doing it, and what it will do. It contains details about user needs, business drivers, design principles, the core conceptual model of how people do things, and the core interactive model that the design needs to follow. A potentially more approachable way to think about it is to look at it as a brief such as one that would be given to an ad agency, a “project charter” for a UX team. So, now, the big question: how do you create one, and how do you use it? The following sections outline what I have done on a couple of projects to create a high level design.
First, know what you know.
Even if you haven’t formally done any research in the domain you are designing, you probably already know a lot about the space. Get it down. Do you have access to any research about what you are doing? Study it, and capture the key learnings that can apply to this project. Have different people look at the same data, to get a different perspective. Throw all this stuff up on the walls where you are working, and do an affinity exercise to organize it and identify trends and patterns.
Talk to business stakeholders
Get a sense of what is important to them on the project, and capture what they know. Depending on the experience of the people involved, they may be able to provide volumes of contextual information and understanding. An added bonus: you can capture, and keep in mind, the business goals of the project, to sanity check the design work against.
Define who you are designing for
Use or create personas to have an empathetic “target” for your work. Capture and/or define the “I want to” users bring to what you are creating. Understand the emotional and rational landscape that exists in the space, so you can either align with the desires (“I want to be noticed”) or identify potential points of resistance (“I don’t want to spend a lot of time doing X”).
Create a conceptual model
Visualize the space in a way that represents what people do in the domain you are presenting, based on all of the above “intelligence” you have gathered. Keep it simple and approachable, and consider using visual weighting to represent aspects of the experience that is more important than others. A quick case study: My team created a model for mobile banking that represented what people did in a mobile banking context. We identified five areas of action, and also noticed that, frequently, one action could lead to another. The visual we did presented the interconnective aspect of the domain and highlighted the key actions. It was very helpful as a reference doc that we could then “map” features to, and therefore prioritize them.
Sketch and collaborate
Take all the above and start sketching out how it could work. Usee key functions as the basis of what you are sketching. “Sketchstorm” together, to compare and share ideas. Through elimination and discussion, identify some key sketches and ideas that look best. Flesh these out in something that you can get feedback on.
Test and refine
Get the conceptual sketches out to users. See if they can understand how the intended UI would work. Have the participants describe to you how it would work, to see if it is obvious enough and quickly understandable. Refine the design based on testing.
Create a draft information architecture
Group the functions and the information, using the aforementioned conceptual model to group like things and to make the more frequently accessed “stuff” be front and center, and the less important “stuff” at a lower level.
Define the interaction model
This is more for a mobile or table app than a web app, but you need to define how users engage with the information and functionality. Is it pinch? Swipe? Using pagination?
Document and package
It can be contained in one page or a hundred pages, but the more concise you make it, the better. Present it to stakeholders to get buying and (if needed) approval. Keep all your working artifacts if you need to use them to “show your work” to any skeptics.
Doing a high level design is absolutely crucial to ensure success. It allows everyone to create and share a core vision as to what they are doing, a vision that the design team can then follow through on and quickly execute. Try it, it works.