When it comes to filling key leadership roles, many large companies are asking candidates to detail their plan for the 30, 60 and 90 day on the job during the interview process. What is the new hire going to do to make a mark and maximize their impact in that first quarter? The answers to that question could be the difference between being hired or… not.
As UX professionals, I recommend we look at product design and research the same way. If we are designing a new product (or tasked with a major revision of an established product) we should plan out our design work to establish “phase gates” for the work. This will allow for the work to be “timeboxed” so that the team can avoid the classic project management “the work expands to fill the time allotted” situation. This will also help with focus and prevent “overdocumentation” of a solution.
(If you are working in an agile environment, you can call the first 30 days “Sprint 0” and chunk the work for the following 60 days into whatever sprints take place in that time – and track the tasks through the team’s Kanban boards.)
The first 30 days:
Review legacy product research
The first 30 days should be all about learning – what is the product, what are the standard use cases, how many users, etc. Since even “new” products are informed by some level of market research, spend some time reviewing and understanding this information. And (if you can) identify any gaps in this information that can be filed through research (either by you or by other teams in the organization).
Analyze and review competing (or similar) products
Always useful as an exercise is a competitive analysis of the products that are in the same “category” as the one you are working on – What works, what doesn’t, and what are de facto “standards” that should be leveraged in your designs. Also, if you have any psycho-graphic/demographic data on the end-users of the product, it may be useful to also analyze the most popular applications that exist for these users. As I often say, you are not competing with say, another banking app – you’re competing with the last best experience that user had.
Interview stakeholders
This is obvious, but I’m still surprised how many people skip this step. Stakeholders provide a key perspective into the product that you will not see. And if you are working in an environment where a service design blueprint is going to be produced you’ll need to get the stakeholder’s feedback to inform the creation of this document (specifically the “baseline” service design blueprint of the current experience.
Identify the measures of success
At the end of the day, what does success look like? Every project in every organization around the world has some form of success criteria – even if it is not shared or clearly defined. Whether it is retention, sales, “stickiness”, support… or some other KPI (key performance indicator), knowing what will make the product successful (and make the product owners happy) allows the design team to identify what parts of experience to focus the most effort on… Even though that may not be the key needs of the user (more on that later).
Analyze (any) telemetry data
I like both qualitative and quantitative data, and the more information you can study – the better. You may not have any analytics to look at, but if you do have access to such things take full advantage. As Sherlock Holmes once said, “You cannot make bricks without clay.” Use your clay.
Ideate new features using design thinking
Consider running a design thinking workshop with your stakeholders and (if possible) end users. This will allow you to identify and define new features that can potentially be added to the backlog and produce a “game changer” app. I’m a big proponent of this technique to ideate and innovate, and in the worse-case scenario… it’s a good team bonding activity.
Build your research protocol
By this point, you should have a good sense of who your users are and who you should target for research. So, build that research protocol! Define the Who What When Where and Why and zero in on how people use the current solution – or could use the proposed application. Identify the best and fastest way to find out the information you need. And be result minded – What do you need to know to design a solution (and help) these users?
The next 30 days:
Execute your research
Surveys, Questionnaires, ethnography, Interviews… Try and do as much high-value impactful research as you can. I personally prefer ethnography for a new product/application, and interviews and focus groups for an existing solution. But, again – be goal-minded. Don’t do research “just” to do research. And to state the obvious, analyze the data you gather to identify actionable insights.
Populate the backlog with features
Leverage your research insights to define new features for the product backlog. Leveraging the user story format, frame the feature from the perspective of the end-user. Partner with the Product Owner to be an advocate for the user, and balance out the user needs with the business priorities.
Set your focus
Use the user research to inform what key features of the application is the “mush have” for users. As detailed above, make sure this is not in opposition to the key business drivers from the product team. Optimally, what the user needs is directly aligned with what the Product Owner wants to provide for the customer.
Design your MVP (Minimal viable product)
Define the core of the experience – what are the “must-have” features that you cannot “ship” without. Again, this involves some “horse trading” with the product team. Be confident in speaking out and being an advocate for the user when you state your case, but be mindful of the aforementioned KPIs and business goals. Again, horse trading.
Validate the designs with the technical team
Once the initial design is defined, make sure that it can actually (oh, I don’t know) be BUILT. This means partnering with the development team to ensure that the design is feasible. Optimally, the development has been involved and collaborating with you from the beginning, but (unfortunately) silos still exist in companies.
The last 30 days:
Build your prototype
Using whatever approach makes sense with the time and skills available, build a prototype. Use design tools (like Adobe XD or Sketch) or actual cool to make it interactive and as “real” as possible. Make sure the core features of the MVP is reflected in it, and use it to communicate the design to stakeholders and any interested parties.
(You may have noticed that I did not make this step “document” your design. That’s because design documentation adds a level of detail and work that IMO adds very little value for the effort invested. Making a prototype allows you to better “message” the design to everyone and also prevents misinterpretation and confusion.)
Test the prototype
Do the first round of user testing with the prototype in order to identify any “show-stoppers” that the interaction design may have that you have not identified. Also to see if the design resonates in a positive way with users. Products are equal part practical and emotional, and how it makes people “feel” could be the difference between a successful or a failed product.
Iterate (and then test some more)
The point of testing your product design is to make it better. The end. So if you don’t refine and improve your design based on test results and user feedback, then… why test? Feedback is a gift. Use it to make the product better. Tweak, change, and test again.
Update and prioritize the backlog
Now that you have had (at least) three chances to get user feedback, have another conversation with the Product Owner to re-prioritize and refocus the backlog to bring the most important user stories to the fore. And get used to doing this – because refactoring and refining the product backlog is a key part of the Agile product development process. Continue to represent the user and speak for what they need and how they work.
There you have it… The 90-days kick-start to designing a product. You will continue much of this motion throughout the life-cycle of the product, and you will “tune” your approach continuously based on market forces and user feedback. Good luck!