description | image | projectUrl | team | tools | published | title | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Why amenities are important |
which-nft-image |
|
|
true |
Outdoor Music Venue |
Intro
Getting in and out of a concert venue should be a walk in the park. Surely it lives on a website somewhere. Unfortunately, there was no such authority for parking, drop-offs, umbrella purchase, or getting in or out of this Chicago music pavilion. Chicago is my home -- so let's make one.
I will show that if you are in the business of gaining a headcount, you must close the gap around the experience multiple resellers are giving. Your name is on the line. Just know the circumstances. You might be designing for a city or public space wanting to lend out the land for use by a bank to the end of getting their name to the masses for a summer.
With a few items, you can bridge this gap. I am also going to show you how my motivation to set guardrails in design when trying to buy tickets reflected the initial state of scattered resources to completing a concert experience.
Solution
Stay close to the true quality of attending a concert. Focus on what you can. Set up process guardrails where possible. Wanting to get away with doing less conjures regret at the wrong time: Close the end of our work in a given week precisely when you want to do more.
A mobile task may start with any number of circumstances:
- a text
- a crowded room request
Research
Personas in their respective situations lead me to think about obstacles to completing a ticket booking or similar. Venues want to sell tickets without being in the music business.
What will kill the experience is cutting up the sales streams to multiple parties, each with their respective interest in the post-sale experience. You buy into an idea that as long as there is a copyrighted song coming out of those speakers, it doesn't matter the avenue of payment. It is good to be aware of this.
The past three renames were sponsored by banks.
The personas showed us the possibility of one user being the organizer of a group of friends. That had to be factored in. Design for groups if groups are what your business gets.
At first glance, it seemed that the previous design effectiveness was buried under confusing search engine results.
The step that precedes the user flow depends on finding the right site.
I want awareness of the user frustrations to be a top priority. I will deal with that as far as I what I can control. This is not a priority as it currently stands.
I made sure to take a status snapshot of what I was thinking on loose-leaf paper.
Planning reading into user goals
Asking natural questions is had when you have to ignore a script. At least it is in your own words.
I knew I failed to get comfortable. It was tough to immediately to move past it. Deadlines were not set, only tasks delegated. Like an overweight plane, you have too much precisely when you don't need it.
I assumed a mechanical process would play out when conducting an interview. If X then Y. I thought that if my questions were well-prepared, my best laid plans would feel like a conversation. Sterile convos might lead to curt responses where I need deep recalls about a certain time in their life.
A more relaxed stance did naturally kick in at about 1/4 of the way through the research interview. I managed to get on track, but only after I started writing my reflections at the end of the day. I did that with some help even.
Previous design decisions were not where I needed them to be.
Ticket sales were of a separate focus than sites that emphasized navigating the venue. Recognize venues that are not perfect lots.
The users' case for wanting to find amenities was injected and assumed early. Assumptions usually carry liability.
I mean, they already bought tickets.
I worked to design the map.
I played around a bit with the actual start of the experience of a user. I tried to place where you primary buy tickets. I also tried one flow where you start already at the show. That is only 50% of the battle.
I armed the app for relevance, attaching a map with the understanding that visualizing the stadium is what the user shapes in their mind as something now relevant to them. The current map is Chicago.
But have I broken it? Maps take screen real estate especially on a phone. Is my visualization so specialized that it can break visual hierarchy, for example?
What could be a way to find out how many tickets groups of users buy fter all this is implemented?
I had required myself to get through this task by sketching and understanding the likely user.
I fell short on welding visualizations together with the process, opting to focus on the finish line. The result is a slightly partitioned experience. Yet it was less partitioned than finding the right website with the right details.
My delivery felt uphill. The process was freeform. Few guardrails were set up after research. I would rather set up guardrails.
I noted that this venue had a weird seating format. Asking people questions about getting to that particular venue, and how it revolved around parking, I was right to think so.
Bad weather
The interviews were conducted to shed light on a representative user.
No umbrella and worrying about seat squatting are issues. Navigation in a possibly new venue is also a frustration. Interviews were a natural step to narrowing down these frustrations.
Any apps that lose are any that fail to weigh in the core concert experience.
What would this look like in a different city, aside from the map? It would.
The business, however, was regional in the sense that the information you get to go to a concert is in a different place than where a user would learn dates, times, rules, and same-day setups.
City by city placement is a next step that can use further discovery.
Testing
The data from gathering user test showed there was an emphasis needing to be placed on the calendar.
Step in, address, discuss. You cannot yet buy tickets.
Conclusion
Align and time box. Time pressure is coming. Work with what you have.