Image credit: Kelly Sikkema
Establishing an approach to competitive analysis.
Despite it being included in last week’s content, I decided to complete my competitor analysis this week so it was fresh in my mind to inform my wireframing. It turned out to be a bit of speed bump in my design journey.
The first challenge was in finding an approach to completing competitor analysis. Nadja Hatzijordanou, Nicolai Bohn & Orestis Terzidis, 2019, acknowledged competitor analysis as a cornerstone of strategic decision-making; without sufficent competitive intelligence, implementing a business strategy could lead to critical failure.
My concern was that taking inventory of near competitor’s feature set could lead to me creating a carbon copy of their app in place of any strategic decision making, especially if I lost track of my personas along the way. Keeping empathy with my users front-of-mind, I decided that it would be better to gain experience of the competitor app by using it as any of their users would. Once I had established my own conceptual model of their app, I could start to consider how my personas would experience it.
In effect, I’ve carried out a longitudinal competitor analysis of a well-established fitness tracker app, Strava. Since starting to use Strava, I have kept space on my whiteboard to log the pluses and deltas I have encountered in the app.
The insights that I have gained have been valuable, but my process has undeniably lacked structure. Next time I take a longitudinal approach to competitor analysis, I should maintain a table, tracking my competitors key features, strengths and weaknesses (Kathy Baxter, Catherine Courage, and Kelly Caine, 2015 p.34).
Competitor analysis from the affective domain.
Here, I refer specifically to one of the five reflective domains; Dispositional, affective, interpersonal, cognitive, and procedural. The affective domain concerns refections on feelings, experiences, and emotions (Alcwyn Parker, ca. 2020).
The second challenge I encountered whilst carrying out my competitor analysis was more internal. As mentioned above, I signed up for Strava with the intention of understanding its user exeperience.
As it turns out, I’ve really enjoyed sharing my run logs with friends on social media. Yesterday evening, I managed a 6.5km run, and I have no intention of stopping there. I’ve found that I’ve been more focused and present during the day, and I’ve slept better at nights.
I’ve since shifted focus away from competitor analysis, yet I’m still using Strava. It has successfully retained me as a user. My interaction with Strava has been so positive that I’m now a little bit disillusioned with my idea.
I reflected on an instance of frustration in week 2, module 1 that I believe is relevant here:
“What draws the line between positive and negative is my response. I could let it impede my ability to work. Worse, create an unhappy environment for myself and my colleagues. Or I could identify the source of frustration, resolve it, and work better than ever.
Best practice in the face of frustration is to be remediative, not reactive.“
Dwelling on the fact that I’ve lost confidence in my app could make the next few months a bit tedious. Or, I could remind myself that I am not my user, and though I have been satisfied by Strava, my concept is still grounded in research.
Besides, all of this is still within the context of free practice. My objective for this prototype is to explore and learn, not to make something that’s market-ready.
First visualisations.
Off the back of my competitor analysis, I had wittled my concept from a hazy cloud of HMW statements and half-ideas, down to a somewhat defined feature set with some flow— albeit still all in my head. It was time to start wireframing my idea.
According to Adrian Mendoza, 2013 p.67, a wireframe enables us to document the narrative and intent of our experience, and doing so correctly “will make it easier for a visual designer to create the UI design and the mobile developer to build it”. Personally, I see the wireframe as a means of refining narrative and intent, rather than documenting them.
I agree that wireframes should be shared with UI designers and developers, but on the basis that they could contribute ideas to the form of the product in its early iterations. If the objective is to aid visual designers and developers, I would suggest that the appropriate deliverable is a higher-fidelity prototype. At least, higher-fidelity than the analog wireframes that I typically produce. I’d expect a product to go through a lot of iteration and refinement from its wireframe form – it seems counterproductive to commit time and effort to UI or code before the user journey is reasonably pinned down.
In a post on Medium, Romy Misra, 2016, documented Tina Chen’s, Slack design lead’s, approach to wireframing, and it seems that Tina and I have similar approaches. After completing user research, and before the actual sketching, Tina lists a working feature set to inform the screens in the wireframe. Naturally, I did the same:
- Account creation and login
- find and connect with other users
- Feed of followed users’ run activities
- Invite other users to a party (run lobby)
- accept invites to a party from other users
- run lobby VoIP
- real-time run stats
- post-run breakdown (route, stats, points earned – for self and party)
- run records
- Points balance
- ticket wallet
- Purchase train tickets
List of Figures
Fig. 1: A photograph of my analog concept wireframe
References
BAXTER, K., COURAGE, C. & CAINE. K. 2015. Understanding Your Users: A Practical Guide to User Research Methods. 2nd edn. Amsterdam: Elsevier, 34.
HATZIJORDANOU, N., BOHN, N. & TERZIDIS, O. 2019. ‘A systematic literature review on competitor analysis: status quo and start-up specifics’. Management Review Quarterly, 69, 415–458.
MENDOZA, A. 2013. Mobile User Experience : Patterns to Make Sense of It All. Amsterdam: Elsevier, 67.
MISRA, R. 2016. ‘How to approach wire-framing an app from scratch: Solve a problem with Tina Chen, design lead Slack’. Medium [user generated content]. Available at: https://medium.com/flowcap/solve-a-problem-with-tina-chen-a83419b209b5 [accessed 16/05/2021].
PARKER, A. ca. 2015. ‘Holistic Reflection: The Five Key Skill Domains’. Falmouth University [online Lecture]. Available at: https://flex.falmouth.ac.uk/courses/872/pages/week-5-the-five-reflective-domains [accessed 16/05/2021].
Skoobin Design 