Design for your future users: building a concept team
This post is a summary of my talk at UX camp Brighton and my workshop at ux-live
At Usabilla, our goal is to help our customers collect feedback in the most innovative way; now and in the future. However, day-to-day issues and current development work tend to occupy our Product and Development teams, leaving little to no room for strategic thinking.
About half a year ago, we decided to kickstart a new initiative: The Usabilla Concept Team. Today, we would like to share our experiences with creating and optimizing a Concept Team as well as give you some pointers about how you too can start a Concept Team and design for the future.
Why build a concept team?
At some point we realized: if we wanted to be truly innovative — which we did — we would need to approach our Product design and development from a higher, more strategic level. Not necessarily ad-hoc or based on a customer’s specific request.
What were common grounds between individual feature requests? What did our customers really struggle with? How could we solve their problems, today and tomorrow?
This made it clear to us that we needed to collect these issues that our customers were facing, combine them with the ideas we had and turn those ideas into actual features for our product roadmap.
At this point we decided to build a Concept Team; an interdisciplinary team that would step away from day-to-day development and dedicate themselves to problems that needed to be tackled in the long-run. This team could ensure that:
- Assumptions, ideas and questions that our organization had could be tackled
- We were able to create and maintain a competitive advantage in the long-run
- Our roadmap would become and remain more UX-driven
What is a concept team?
A Concept Team is an interdisciplinary, but UX / Design driven team that explores the future of a product on a conceptual level in so-called “Concepts”.
Concepts are high-level ideas that are not necessarily tied with what is currently being built in the company, they are the northern star we should move towards.
The Concept Team needed to be able to work independently, while still forming a connection with the rest of the company. We also realized that we needed to adopt a way of working that allowed us to explore concepts, while iterating, failing and succeeding fast.
If you are facing the same issues as we did, trying to adapt your product design and development strategy to future needs, a concept team might work for you. We gathered our biggest learnings and processes to get you started.
Gather a team
We started by assembling a team. Our top priorities were: Be future driven and able to look beyond the current problems and products
- Include different perspectives in an interdisciplinary team
- Be able to operate as a standalone team. Team members needed broad skill sets and to tackle different tasks as needed
- Be able to feed solutions back into the rest of the organization albeit being a standalone team
Taking these facts into account, we went on to recruit the following team members:
- A dreamer, a UX Designer to lead the project and come up with innovative, game-changing, creative ideas.
- A reality checker, a Product Manager to be responsible for evaluating the business value of concepts and ensure alignment with the roadmap.
- A technical perspective, a Developer to evaluate feasibility as well as technical innovation of Concepts.
- An empathy specialist, a Customer Representative, who brings customer experience into the team.
The Concept Team would report to a group of stakeholders. In our case, these were our CEO, Head of Customer Success, VP of Engineering and our VP of Product.
We also created some Concept Team roles which we divided among team members. The roles were based on Google Ventures Design Sprint roles.
Structure your Concept Team
We had a team, great! Now we had to figure out how to create a productive working structure. Even though conceptual work gave us the freedom to dream big and explore new ideas, we had to make sure our concepts does not end up in limbo instead of our roadmap and that we are adding value to the company. So we came up with a plan:
Dedicated Concept Days
In our case, the team members blocked two-four hours “Concept Team slot” each week. During this weekly time, team members were not involved with their regular work. Dedicating specific time to the concept team’s work helped team members to fully immerse themselves in the concept team.
We decided to not go for a full-time team because we wanted to ensure a connection to the rest of the organization. We were worried that the team would become too isolated if they were together all the time.
Sprint Rhythm
For the dedicated Concept Team slot, we also created a sprint rhythm that helped us to set dates and expectations for our deliverables.
Each sprint cycle took about 4 weeks. After each cycle we scheduled update meetings with our stakeholders, product and development teams as well as with the rest of the company. This is how we structured our sprints:
- Step 1: Problem definition, brainstorm and sketch
- Step 2: Design a solution and create a prototype
- Step 3: Validate the Concept
Have your research in place
When we started the Concept Team we found that many of the resources we wanted to use were either not available or not up-to-date. We found surveys and interviews that had been conducted with the intention to create user personas. However, they were incomplete and largely outdated.
We decided to conduct our own research. We organized user interviews, explored every edge of our current product and mapped it out. We also created customer journeys to identify our customers’ ways of working as well as their biggest pain points.
While all this research that needed to be conducted initially seemed to be a setback, it actually proved a great opportunity to get to know our Product and our customer base very well.
Dive into the topic
Now it was time to really dive into the topic. For each concept we needed to gather more information. We talked to our colleagues, identified the most urgent issues regarding the topic in question and uncovered ideas and thoughts that had come up before without ever being picked up. We looked at feedback that has been collected on the topic in the past but also ran Usabilla surveys to increase our understanding of the topic at hand.
Step 1: Problem definition, brainstorm and sketch
Based on this we established a solid problem definition. We then brainstormed and listed every possible aspect that we would need to think about.
In order to design a solution that worked for each user, we defined scenarios for each persona in which they needed to work with our Concept. For every scenario we added the persona’s goal and listed the steps they would need to take in order to achieve that goal.
Based on these scenarios, we defined a list of assumptions and then design principles based on the assumptions. These assumptions and design principles would not only help us in the validation phase, but they help the rest of the company understand the intention behind each concept. An example of a design principle and assumption is:
Assumption
If we assume that our users don’t work alone on a project but in teams.
Principle
We need to design for collaboration.
InVision wrote a great blog post, which came close to the way we created our assumptions and design principles.
(Individual) sketching
With our design principles in hand, we could finally start putting those thoughts and ideas on paper. After a few sprint iterations, we found a balance between group discussions and individual brainstorming/sketching.
Step 2: Design a solution and create a prototype
Especially (individual) sketching would often help us to sort out ideas in our minds and provide a way to communicate them to the team. Being aligned on ideas and understanding each other’s perspective is crucial. We all know that — if someone asks us to think of a chair — we might end up with completely different images in mind. Individual sketching and then presenting these sketches to one another helps alignment and creating a shared understanding.
Telling the story of a concept
Step 3: Validate the Concept
In order to validate our assumptions and solutions with user test participants, we needed a prototype. Our biggest challenge was finding a way in which we could convey the higher level idea of a concept, without falling into discussions about details such as buttons and colors. We created our own way of prototyping and validating our ideas.
For each concept, we created a storyboard; one narrative that best represents the concept. Every step in the narrative served to test the different assumptions.
Now, we needed to convey our idea. From the storyboard we created an abstract prototype that could be a form of a keynote or short video. Why? Because we learned that if we make a prototype looking different from our current interface, without too much detail we could focus the conversation about the Concept, not the usability.
The abstract prototype was one of the most important things we found that helped us to validate our Concepts.
Get the idea into the roadmap
As mentioned at the beginning of this post, our goal was to explore ideas, turn them into concepts and prepare them for our product Roadmap. In order to ensure that our concepts would actually make it to the roadmap, we consistently grabbed opportunities to present our ideas to the company and challenge them with different teams. Sometimes we would present them at company get-togethers, other times we would simply organize walk-in meetings.
Another thing that we learned is that documentation is key. In fact — when dealing with these kind of teams that work ahead of your product teams, documentation becomes your main deliverable. Your end product is essentially a validated prototype, with deeper underlying research that provides a sense of direction for your Product Teams.
A Concept Team will need to build, iterate and fail fast. It won’t create end-to-end working solutions. This means that your Concept Team relies on the Product Teams to develop your Concepts further. This is what makes proper communication and well-documented processes crucial.
The sooner you start thinking about how you can get your concepts to become actual features, the better. Involve relevant stakeholders early on in the process and make sure that every thought and every idea is captured in writing.
This is what we learned so far. We are very interested in hearing how you deal with future-driven design and what your learnings were. Comment below or reach out!
This post is a repost from the Usabilla blog. Check it here, maybe you will find some more interesting content about UX and CX.
