We recently developed a new website for Sports Retail Management, a garment supply company who brand up clothes for all sorts of clients. This was a fun project (note the lack of "air quotes" it was quite a challenge, but one things we passed onto them was a lesson learned from days of yore...
This website is a brand new one for us, working closely with the client we created a combination site which has a public element to it coupled with a fully functional client extranet. The client Sports Retail Management, came to us with a simple remit, allow our local authority clients to log onto the website under their own account and create garment orders. "Is that it?" Well, kind of... It then transpired that some clients have some discounts afforded to them based on the level of purchasing they do.....ok, that's not a problem. Oh and each garment can have several colours and sizes. Yeah that's fine. Except that some sizes have different pricing models.
OK so this project started to look a little more complicated than initially envisaged so we started to look at how the system would work in the hands of the user, we started with a skeleton of the functional elements and imagined (note that) what features might be useful for the Authority users.
Side note: we pride ourselves on (mostly) listening to our clients regarding what they want and adding value to the systems we develop to make them as intuitive and user-friendly as we can. One of the things we have learned is one, don't overthink something - brainstorming something is useful but only come to conclusions if you are sure the end-user will see and use the value of your efforts. A number of times I've seen projects (which we have inherited) with loads of bells and whistles, so many if them in fact that you can't get to grips with the underlying functional purpose of the project. A developer who can see the actual value (rather than perceived value) and then apply this into functionality is worth their weight in gold, every time.
So, back to the story, we sat down with the end user and asked them what they would use. This was an eye opener - it's all too common to hear our client ask for this and that, without really knowing what their client would see as the priority feature.
In this case there was a large degree of overlap, with one or two things which the client in particular wanted which were not mentioned at all during the development specification phase.
So a lesson learned, not in an accusing manger it's just that sometimes you would be best advised speaking with the end user as the client, like you, will only imagine what can be the best features for a site which is heavily used by clients.
There endeth the lesson...
No comments:
Post a Comment