Crafting a great process takes time. It takes trial and error. More often then not you have to fail as an organization, as a team and as individuals before you can shape the right process.
This is true for us at Made By Munsters. Over the course of eight plus years, our team has seen its fair share of challenges and with those we have succeeded and failed. Yes, I said it. We failed. But it was those failures I enjoyed the most; well maybe not at the time. But I certainly enjoy them now.
OK, you got me. I am rambling. Sorry, this is something I tend to do; just ask my students at Bloc. I’ll get to the point, now. Made By Munsters was recently asked by one of our clients, Red Ventures, to present to a group of their employees about our UX process.
As a company that started out as a user experience and user interface design firm, this seemed simple. But when I started to look back at our old posts, notes and business documents, I couldn’t find any documentation on our process.
Thus, this opportunity gave the team and myself the chance to discuss just how the hell we actually solve problems. We analyzed our current projects, past projects and talked with a few clients. While we do the same exercises for each client it was interesting to hear what our clients and new team members defined our process as.
After collecting our data and analyzing it, here is what we documented:
How We Solve For X
1. Gather all the facts before production.
2. Don’t solve problems that don’t exist.
3. Make an educated guess for the MVP.
4. Create re-usable building blocks.
5. Iterate. Deployment doesn’t mean done.
Gather All The Facts
The first step in building a successful product in-house or for a client is making sure the entire team is on the same page.
At Made By Munsters, we start each project off by conducting an inception workshop. In his workshop we explore what potential problems we need to solve, who we are going to be building this product for and what solutions are good to start testing for day one.
The inception workshop establishes what our team will build and how. We ask that all stakeholders come ready to participate. At this stage of the game, no idea is a bad idea. In fact, the more discussion the team has the better developed the thesis statement will end up.
These meetings can last a few days for large-scale applications; or just a few hours for smaller websites / product build-outs.
After leaving the inception workshop we establish:
1. Who we are building for and what are their problems (user personas)
2. What we are building for those established users (user stories)
3. Establishing our users’ work flows (task flows)
4. What the structure of the product will look like (wireframes)
Solve Problems; Don’t Create New Ones
As a team it’s our goal to only solve problems that exist. We don’t want to create new ones. That’s why we rely on the data we created and found in our inception workshop to guide us as the product develops.
Additionally, we create a thesis statement at the end of the workshop. As fluid as this statement might be, it is a starting point. It helps us as a team to focus on the task at hand. As new ideas enter into the equation during the design phase, we refer back to our thesis statement. If it doesn’t fit, we write the idea down and move on.
Take for instance a project we recently deployed. The goal of the project was to help our client create a simple and intuitive platform to conduct semi-annual and annual employee reviews (our thesis statement).
The ideas we had for this project were endless. One for instance was a way to note how a manager’s employee was doing during the time between reviews. We thought it would be great if a user could log an item from their mobile phone and store it on the employee’s profile. This way they could access it at a later date.
However, having talked to a several managers of the company they explained how little time they spend using features such as this during the year. They open the review application about a month before reviews are due. And while, tracking data and interactions with employees seemed like a good idea to most of them, it was a feature they said they would hardly use.
Because of those responses, we opted to omit this feature. It was a problem not worth solving at this time and in fact might have created a new problem.
Build And Test A Minimal Viable Product
One of our biggest goals of a team is to get a product in the hands of real users as quickly as possible. As a team, along with our clients, we make a strong educated guess for our day one releases.
This allows us to test our ideas and make rapid iterations without wasting too much time and effort. While we never build without collecting data, talking to users and testing design prototypes, iterating on live products allows us to find solutions to smaller problems before they grow out of control.
A couple of things to keep in mind:
1. Don’t build past day one. It is easy to get caught up in the idea of scaling and needing to accommodate hundreds of thousands of users. However, if you don’t have a large user base, then focus on the users you do have. Build for those individuals and solve their problems.
2. Don’t get attached to your designs. Make each view, feature, component fluid. With new data comes new problems to solve and that means changing the designs you pushed live.
Design In Terms Of Systems
There has been a lot of talk on this subject as of late and for good reason. As web designers and developers we have to stop thinking in terms of views or features, but more in terms of systems and components.
When designing large-scale products our company focuses on building Lego pieces we can quickly attach together. This allows us to build new features quickly and test without much effort. If the feature works great. We can go back and polish it. If it fails — and often this happens — we can pull it apart without accruing a lot of technical or design debit.
What do we define as components? To Made By Munsters they are singular design elements that can be used and re-used. Alone they don’t mean much, but when attached to other components, a designer can build structures to produce working views.
What do we define as structures? Made of many components, structures shape the way a view is laid out. It’s important to note that each structure should live independently. If you remove one, the entire view should not come crumbling down.
Lastly, views should be built with many individual components and structures. This allows us as designers to create playgrounds, create rapid iterations and multiple pages that can be tested and vetted until the right combination of components and structures are found.
Deployment Is Not The End
Once we deploy our application we closely monitor it, talk to users and solve any issues that arise. Just because we deployed the application it doesn’t mean we are done.
It is merely the beginning.
It takes time to create a process that works for your team or organization. However, at Made By Munsters we found that following a similar process for each product or site we build has helped to make our releases more successful.
If you want to learn more about our process, watch the video at the start of this post. It is a talk we gave at Red Ventures about our UX design process.